Hi,

Thanks for taking a look at this!


On 8/10/21 5:07 AM, Florian Fainelli wrote:

On 8/5/2021 2:11 PM, Jeremy Linton wrote:

quoted

We are about to create a standalone ACPI quirk module for the
bcmstb controller. Lets move the register definitions into a separate
file so they can be shared between the APCI quirk and the normal
host bridge driver.

Signed-off-by: Jeremy Linton <redacted>
---
  drivers/pci/controller/pcie-brcmstb.c | 179 +------------------------
  drivers/pci/controller/pcie-brcmstb.h | 182 ++++++++++++++++++++++++++
  2 files changed, 183 insertions(+), 178 deletions(-)
  create mode 100644 drivers/pci/controller/pcie-brcmstb.h

You moved more than just register definitions into pcie-brcmstb.h you 
also moved internal structure definitions, enumerations, etc. which are 
not required since pcie-brcmstb-acpi.c does not access the brcm_pcie 
structure but open codes accesses to the MISC_STATUS register instead.

There are no include guards added to this file (it is debatable whether 
we should add them), and it is also not covered by the existing BROADCOM 
BCM2711/BCM2835 ARM ARCHITECTURE MAINTAINERS file entry.

Sure, I will reduce the .h to just the register definitions, guard it, 
and tweak maintainers to cover pcie-brcmstb*.

Given that there can be new platforms supported by this PCIe controller 
in the future possibly with the same limitations as the 2711, but with a 
seemingly different MISC_STATUS layout, you will have to think about a 
solution that scales, maybe we cross that bridge when we get there.

Yes, given I don't know what those changes are I can't predict how they 
would have to be handled, or even if the platform would be a target of 
the community maintaining the UEFI/ACPI port on the RPi. So punting on 
that topic seems a reasonable solution at the moment. Better yet, more 
of the linux community will see the advantage of the firmware interface 
and this platform can utilize that method.