Hi Marek,
On 30 August 2018 at 03:25, Marek Vasut marek.vasut@gmail.com wrote:
On 08/30/2018 02:29 AM, Simon Glass wrote:
Hi Marek,
Hi,
[...]
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
- Simon
[...]
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
We do, since there seems to be usecase for those too.
OK, well let's make sure we have some compatible notes too in sandbox, so we retain testing.
I'm not changing anything in sandbox, so the original case is covered as is.
-- Best regards, Marek Vasut