Re: [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list management to drivers/acpi

[Tomasz Nowicki]

Hi Bjorn,

On 03.03.2016 23:51, Bjorn Helgaas wrote:
> Hi Tomasz, Jayachandran, et al,
>
> On Tue, Feb 16, 2016 at 02:53:31PM +0100, Tomasz Nowicki wrote:
> > From: Jayachandran C <jchandra@xxxxxxxxxxxx>
> >
> > Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
> > to share the API and code with ARM64 later. The corresponding
> > declarations are moved from asm/pci_x86.h to linux/pci-acpi.h
> >
> > As a part of this we introduce three functions that can be
> > implemented by the arch code: pci_mmconfig_map_resource() to map a
> > mcfg entry, pci_mmconfig_unmap_resource to do the corresponding
> > unmap and pci_mmconfig_enabled to see if the arch setup of
> > mcfg entries was successful. We also provide weak implementations
> > of these, which will be used from ARM64. On x86, we retain the
> > old logic by providing platform specific implementation.
> >
> > This patch is purely rearranging code, it should not have any
> > impact on the logic of MCFG parsing or list handling.
>
> I definitely want to figure out how to make this work well on ARM64.
> I need to ponder this some more, so these are just some initial
> thoughts.
>
> My first impression is that (a) the x86 MCFG code is an unmitigated
> disaster, and (b) we're trying a little too hard to make that mess
> generic.  I think we might be better served if we came up with some
> cleaner, more generic code that we can use for ARM64 today, and
> migrate x86 toward that over time.
>
> My concern is that if we elevate the current x86 code to be
> "arch-independent", we will be perpetuating some interfaces and
> designs that shouldn't be allowed to escape arch/x86.
>
> Some of the code that moved to drivers/acpi/pci_mcfg.c is not really
> ACPI-specific, and could potentially be used for non-ACPI bridges that
> support ECAM.  I'd like to see that sort of code moved to a new file
> like drivers/pci/ecam.c.

Actually I split it as you suggested in the previous patch set. Please 
have a look at:
https://lkml.org/lkml/2016/2/4/646

Especially patches [0-6] which handle MMCONFIG refactoring.

Thanks,
Tomasz