Re: [PATCH v10 0/7] PCI: brcmstb: root port turns on sub-device power

On 12/10/21 10:44 AM, Rob Herring wrote:

On Thu, Dec 09, 2021 at 04:13:58PM -0500, Jim Quinlan wrote:

quoted

v10 -- Bindings commit example: in comment, refer to bridge under
       controller node as a root port. (Pali)
    -- Bindings commit example: remove three properties that are not
       appropriate for a PCIe endpoint node. (Rob)

v9  -- Simplify where this mechanism works: instead of looking for
       regulators below every bridge, just look for them at the
       bridge under the root bus (root port).  Now there is no
       modification of portdrv_{pci,core}.c in this submission.
    -- Although Pali is working on support for probing native
       PCIe controller drivers, this work may take some time to
       implement and it still might not be able to accomodate
       our driver's requirements (e.g. vreg suspend/resume control).
    -- Move regulator suspend/resume control to Brcm RC driver.  It
       must reside there because (a) in order to know when to
       initiate linkup during resume and (b) to turn on the
       regulators before any config-space accesses occur.

You now have a mixture of 'generic' add/remove_bus hooks and the host 
controller suspend/resume managing the regulators. I think long term, 
the portdrv is going to be the right place for all of this with some 
interface defined for link control. So I think this solution moves 
sideways rather than towards anything common.

Unfortunately, the only leverage maintainers have to get folks to care 
about any refactoring is to reject features. We're lucky to find anyone 
to test refactoring when posted if done independently. There's a long 
list of commits of PCI hosts that I've broken to prove that. So it's 
up to Lorenzo and Bjorn on what they want to do here.

After version 10, it would seem pretty clear that we are still very much
committed to and interested in getting that set merged and do it the
most acceptable way possible. Common code with a single user is always a
little bit of a grey area to me as it tends to be developed to cater for
the specific needs of that single user, so the entire common aspect is
debatable. I suppose as long as we have the binding right, the code can
change at will.

Not trying to coerce Bjorn and Lorenzo into accepting these patches if
they don't feel comfortable, but what about getting it included so we
can sort of move on from that topic for a little bit (as we have other
PCIe changes coming in, supporting additional chips etc.) and we work
with Pali on a common solution and ensure it works on our pcie-brcmstb.c
based devices? We are not going to vanish and not come back looking at this.
-- 
Florian

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