On Mon, Oct 25, 2021 at 09:50:09AM -0400, Jim Quinlan wrote:

On Fri, Oct 22, 2021 at 3:47 PM Mark Brown [off-list ref] wrote:

quoted

On Fri, Oct 22, 2021 at 03:15:59PM -0400, Jim Quinlan wrote:

quoted

That sounds like it just shouldn't be a regulator at all, perhaps the
board happens to need a regulator there but perhaps it needs a clock,
GPIO or some specific sequence of actions.  It sounds like you need some
sort of quirking mechanism to cope with individual boards with board
specific bindings.

The boards involved may have no PCIe sockets, or run the gamut of the different
PCIe sockets.  They all offer gpio(s) to turn off/on their power supply(s) to
make their PCIe device endpoint functional.  It is not viable to add
new Linux quirk or DT
code for each board.  First is the volume and variety of the boards
that use our SOCs.. Second, is
our lack of information/control:  often, the board is designed by one
company (not us), and
given to another company as the middleman, and then they want the
features outlined
in my aforementioned commit message.

Other vendors have plenty of variation in board design yet we still have
device trees that describe the hardware, I can't see why these systems
should be so different.  It is entirely normal for system integrators to
collaborate on this and even upstream their own code, this happens all
the time, there is no need for everything to be implemented directly the
SoC vendor.  

If there are generic quirks that match a common pattern seen in a lot of
board then properties can be defined for those, this is in fact the
common case.  This is no reason to just shove in some random thing that
doesn't describe the hardware, that's a great way to end up stuck with
an ABI that is fragile and difficult to understand or improve.
Potentially some of these things should be being handled in the bindings
and drivers drivers for the relevant PCI devices rather than in the PCI
controller.

quoted

I'd suggest as a first pass omitting this and then looking at some
actual systems later when working out how to support them, no sense in
getting the main thing held up by difficult edge cases.

These are not edge cases -- some of these are major customers.

I'm trying to help you progress the driver by decoupling things which
are causing difficulty from the simple parts so that we don't need to
keep looking at the simple bits over and over again.  If these systems
are very common or familiar then it should be fairly easy to describe
the common patterns in what they're doing.

In any case whatever gets done needs to be documented in the bindings
documents.