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:
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 <jeremy.linton@xxxxxxx>
---
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.
