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
