On 2/21/20 9:11 AM, Mark Brown wrote:

On Fri, Feb 21, 2020 at 08:33:36AM -0800, Florian Fainelli wrote:

quoted

On 2/21/2020 4:12 AM, Mark Brown wrote:

quoted

quoted

No, this isn't a good idea - the set of supplies the device has is
fixed when the silicon is produced, it's not something that needs to
vary per board.  This means that the binding should have a fixed list of
supplies, per SoC if that's needed.

quoted

These are not the supplies for the PCIe I/Os on the SoCs side, but the
supplies for the PCIe end-point connected to the SoCs. More on that below.

Then the "slots" (obviously at least some of these are soldered down
rather than on actual slots) should be represented in DT and the
controller or bus should know that it needs to iterate over them to
bring up the chips.  I would also expect that there are standard names
in the PCI specs for the standard supplies that go into devices as part
of the bus spec which would mean that there should still be no need to
encode names like this.

Agree.

quoted

If you describe the regulators as properties of the PCIe EP nodes which
are child nodes of the PCIe RC node (as we should), you will not be able
to manage all of them within your pci_driver instance, because if there
is no power to the EP you just do not enumerate it, therefore no
pci_device is created.

The framework and/or driver can enumerate firmware information without
actually powering up the devices of course.

The issue is not enumeration, it is ensuring that you will be able to
establish the PCIe link with the EP. If there is no pci_device created
because the bus scanning returned a link down, there is not much that
can be done. Also the question is whether this logic belongs in the PCI
bus layer or the driver.

I would not be surprised to learn that most systems just mark the device
supplies always on, it's not like the devices will be able to use them
normally anyway.

In the downstream PCIe driver which is this one is just a subset of
until we close the gap, we have some additional logical to determine
whether the EP device is wakeup enabled in order to leave its regulators
turned on during system sleep so as to permit Wake-on-WLAN for instance.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel