On 3/29/21 1:45 PM, Mark Brown wrote: > On Mon, Mar 29, 2021 at 03:48:46PM -0400, Jim Quinlan wrote: > >> I'm not concerned about a namespace collision and I don't think you >> should be concerned either. First, this driver is for Broadcom STB >> PCIe chips and boards, and we also deliver the DT to the customers. >> We typically do not have any other regulators in the DT besides the >> ones I am proposing. For example, the 7216 SOC DT has 0 other > > You may not describe these regulators in the DT but you must have other > regulators in your system, most devices need power to operate. In any > case "this works for me with my DT on my system and nobody will ever > change our reference design" isn't really a great approach, frankly it's > not a claim I entirely believe and even if it turns out to be true for > your systems if we establish this as being how regulators work for > soldered down PCI devices everyone else is going to want to do the same > thing, most likely making the same claims for how much control they have > over the systems things will run on. > >> regulators -- no namespace collision possible. Our DT-generating >> scripts also flag namespace issues. I admit that this driver is also >> used by RPi chips, but I can easily exclude this feature from the RPI >> if Nicolas has any objection. > > That's certainly an issue, obviously the RPI is the sort of system where > I'd imagine this would be particularly useful. > >> Further, if you want, I can restrict the search to the two regulators >> I am proposing to add to pci-bus.yaml: "vpcie12v-supply" and >> "vpcie3v3-supply". > > No, that doesn't help - what happens if someone uses separate regulators > for different PCI devices? The reason the supplies are device namespaced > is that each device can look up it's own supplies and label them how it > wants without reference to anything else on the board. Alternatively > what happens if some device has another supply it needs to power on (eg, > something that wants a clean LDO output for analogue use)? > >> Is the above enough to alleviate your concerns about global namespace collision? > > Not really. TBH it looks like this driver is keeping the regulators > enabled all the time except for suspend and resume anyway, if that's all > that's going on I'd have thought that you wouldn't need any explicit > management in the driver anyway? Just mark the regualtors as always on > and set up an appropriate suspend mode configuration and everything > should work without the drivers doing anything. Unless your PMIC isn't > able to provide separate suspend mode configuration for the regulators? > We have typically GPIO-controlled and PMIC (via SCMI) controlled regulators. During PCIe enumeration we need these regulators turned on to be successful in training the PCIe link and discover the end-point attached, so there an always on regulator would work. When we enter a system suspend state however there are really two cases: - the end-point supports Wake-on (typically wake-on-WLAN) and we need its power supplied kept on to support that - the end-point does not support or participate in any wake-up, there we want to turn its supplies off to save power How would we go about supporting such an use case with an always on regulator? -- Florian
