[U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

[Marek Vasut]

On 08/23/2018 04:11 AM, Bin Meng wrote:
> Hi Marek,

Hello Bin,

> On Wed, Aug 22, 2018 at 5:57 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>> On 08/22/2018 04:14 AM, Bin Meng wrote:
>> [...]
>>>>>> I said in the previous discussion I am willing to update the
>>>>>> documentation to match the implementation, but that's about it.
>>>>>>
>>>>>>> So far almost all PCI device drivers in U-Boot supports both
>>>>>>> scenarios, except PCI UART which currently only supports scenario#1.
>>>>>>> If you declare what you do in this patch is pureblood then you should
>>>>>>> revoke the other 2 at the same time. Leaving such in the mainstream
>>>>>>> only creates chaos in the future and we should avoid doing that, given
>>>>>>> we already had lots of discussion here.
>>>>>>
>>>>>> No. The compatible is valid for some PCI subdevs, ie. bridges, so that
>>>>>> has to stay. You also need compatible for sandbox, you said that
>>>>>> yourself. And declaring a PCI device with BFD in DT is needed, ie. for
>>>>>> the r8a7794-style bindings.
>>>>>>
>>>>>
>>>>> OK, now new comments :) So you admit "compatible" can be valid for
>>>>> some cases.
>>>>
>>>> _some_ select ones, and that is a _very_ important distinction.
>>>>
>>>>> I have to point out that your theory on PCI device probing
>>>>> is self-contradictory.You refuse to add a "compatible" string to your
>>>>> PCI device because you said the vendor/device id/class provides enough
>>>>> information to bind the driver, then why do you want to specify your
>>>>> devices in the device tree in the first place.
>>>>
>>>> Because of the USB PHY , which is attached to that device and can not be
>>>> probed on the PCI bus, unlike the device itself ?
>>>>
>>>
>>> You can create a new EHCI PCI driver to match your USB EHCI
>>> controller's vendor id/device id, and do any additional PHY setup in
>>> that driver. BTW what's the vendor id and device id of the EHCI
>>> controller on your board? I can have a look up at the PCI database.
>>
>> You can not.
>>
>> 1033:00e0 -- https://pci-ids.ucw.cz/read/PC/1033/00e0
>>
>> You can buy that controller as a discrete chip on a PCI card or have one
>> in an SoC on a PCI bus, I have both.
> 
> Hardware vendors like to create such fantastic stuff in their SoCs,
> sigh. So how about subvendor and subdevice id? The embedded one can't
> be the same as the the discrete one. If they are really all the same,
> then why can't we add a specific compatible string to describe such
> device? The compatible idea was invented to describe devices that
> cannot be discovered via some probeable ways.

I cannot if you look at the r8a7794 PHY phandles in the DT. The PHY
connects to two devices and this is well modeled in DT.

>>>>> According to your
>>>>> theory, "Each PCI device already has a PCI ID and class which is used
>>>>> to identify it and based on which the drivers bind to it, so a DT
>>>>> compatible is NOT needed and is actually redundant and harmful.", I
>>>>> would argue why not just creating a dedicate PCI device driver using
>>>>> PCI ID and class information to do the driver binding and start from
>>>>> there.
>>>>
>>>> Because the same device with the same PCI ID can be used without that PHY .
>>>>
>>>>> As you mentioned PCI bus is probable bus like USB, everything
>>>>> can be self-contained in the PCI device driver itself. There is no
>>>>> need to create nothing in the device tree. If you want an example,
>>>>> check 8250_pci.c in the Linux kernel. Everything that is needed to
>>>>> configure the driver is included in the driver itself. It does not
>>>>> read anything from the device tree.
>>>>
>>>> Well, see above for why this approach doesn't work.
>>>
>>> Please explain why it does not work. I see Intel e1000 driver in the
>>> Linux kernel has lots of PHY configuration within the driver. It does
>>> not use any external PHY (eg: Marvell 88exxx) driver that Linux
>>> already has. The Ethernet PHY are not probeable on the PCI bus too.
>>
>> That's a different thing, the ethernet MACs have an internal MDIO
>> interface and you can scan the MDIO bus and read out PHY registers 0/1
>> to get the PHY ID.
>>
> 
> Yes, I know. But my point is that Linux drivers are not always
> consistent. There is diversity and Linux is fine with that. There is
> also diversity when it comes to U-Boot PCI support and we have 2
> supported PCI scenarios, the 1st of which can satisfy your use case.
> 
>> This does not apply to this particular usecase here. In this case, the
>> controller can be either embedded or discrete, with PHY or without PHY.
>>
> 
> Does the embedded one have no register that can identify the PHY presence?

No, why would it ? They are two completely separate blocks .

[...]

-- 
Best regards,
Marek Vasut