Re: [PATCH 1/3] PCI: brcmstb: Break register definitions into separate header

From: Florian Fainelli
Date: Wed Aug 11 2021 - 04:39:59 EST




On 8/10/2021 8:10 AM, Jeremy Linton wrote:
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.

Ideally newer platforms would support ECAM and would not require a custom quirk if nothing else, we do have discussions about that right now, although it is not clear to me how it will materialize into a product that people can buy.
--
Florian