Re: [PATCH V3 18/22] LoongArch: Add PCI controller support

From: Bjorn Helgaas
Date: Tue Sep 21 2021 - 18:36:20 EST


On Sat, Sep 18, 2021 at 03:36:52PM +0800, Huacai Chen wrote:
> On Fri, Sep 17, 2021 at 5:02 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@xxxxxxxxxxx> wrote:
> > >
> > > Loongson64 based systems are PC-like systems which use PCI/PCIe as its
> > > I/O bus, This patch adds the PCI host controller support for LoongArch.
> > >
> > > Signed-off-by: Jianmin Lv <lvjianmin@xxxxxxxxxxx>
> > > Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx>
> >
> > As discussed before, I think the PCI support should not be part of the
> > architecture code or this patch series. The headers are ok, but the pci.c
> > and acpi.c files have nothing loongarch specific in them, and you clearly
> > just copied most of this from arm64 or x86.
>
> In V2 part of the PCI code (pci-loongson.c) has moved to
> drivers/pci/controllers. For pci.c and acpi.c, I agree that "the thing
> should be like that", but have some different ideas about "the way to
> arrive at that". In my opinion, we can let this series be merged at
> first, and then do another series to "restructure the files and move
> common parts to the drivers directory". That way looks more natural to
> me (doing the other series at first may block the whole thing).
>
> > What I would suggest you do instead is:
> >
> > - start a separate patch series, addressed to the ACPI, PCI host driver
> > and ARM64 maintainers.
> >
> > - Move all the bits you need from arch/{arm64,ia64,x86} into
> > drivers/acpi/pci/pci_root.c, duplicating them with #if/#elif/#else
> > where they are too different, making the #else path the
> > default that can be shared with loongarch.
> >
> > - Move the bits from pci_root_info/acpi_pci_root_info that are
> > always needed into struct pci_host_bridge, with an
> > #ifdef CONFIG_ACPI where appropriate.
> >
> > - Simplify as much as you can easily do.

I would love to see this done.

But we already have this kind of redundant code for arm64/ia64/x86.
Arguably, we should have refactored it for ia64 or arm64. It's
unfortunate to add loongarch to that list, but why should we penalize
loongarch more than arm64 and ia64?

Bjorn