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

Jeremy Linton jeremy.linton at arm.com
Tue Aug 10 08:10:30 PDT 2021


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 at arm.com>
>> ---
>>   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.



More information about the linux-arm-kernel mailing list