From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 23 Aug 2018 09:42:13 +0200 Subject: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes In-Reply-To: References: <6aa50a30-df29-07fe-4d12-f9cbdae82df1@gmail.com> <8c47a8b1-13ea-d0b1-cca2-a4d51bc566a4@gmail.com> Message-ID: <36c1bbd9-4230-f46c-c77f-a683a74afe2d@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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