Re: [PATCH v2 1/2] PCI: brcmstb: Add regulator support

[Florian Fainelli <f.fainelli@xxxxxxxxx>]

On 2/21/2020 4:12 AM, Mark Brown wrote:
> On Fri, Feb 21, 2020 at 12:36:39PM +0900, Jaedon Shin wrote:
> 
>> +  supply-names:
>> +    description: List of regulator supplies to use for PCIe
>> +
> 
> 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.

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.

What I suspect is going on is that Jaedon wants to use the canonical
bootloader from Broadcom which provides the supplies in way that they
are properties of the PCIe RC node as opposed to properties of the PCIe
EP node. This has been done historically because there is a chicken and
egg problem and we did not know or could solve this at the time.

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.

It seems to me that what we are missing is some logic within the PCI
subsystem that is able to parse regulator/resets properties and ensure
that they are enabled in order for a PCI bus scan to succeed. Jaedon, do
you feel like taking on this effort?

>From these existing bindings:

Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt
Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt

it seems to me that they are all describing the supplies from the SoC
side, but not sure, there may have been a precedent for a similar
simplification.
-- 
Florian