[PATCH v1] x86: acpi: Refactor XSDT handling in acpi_add_table()

[Andy Shevchenko]

On Mon, Mar 2, 2020 at 9:47 PM Simon Glass <sjg at chromium.org> wrote:
> On Fri, 28 Feb 2020 at 01:47, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
> > On Fri, Feb 28, 2020 at 1:41 AM Simon Glass <sjg at chromium.org> wrote:
> > > On Thu, 27 Feb 2020 at 06:00, Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> >
> > > Could you take a look at the ACPI series?
> > >
> > > It was sent out about a month ago and has a refactor to this function.
> > >
> > > u-boot-dm/coral-working
> >
> > There are tons of changes. Care to point what changes are more
> > important (generic to all x86)?
>
> I'm not quite sure about that...but x86 patches have an x86: tag, so
> perhaps that helps?

Okay, some like 50 of them or even more? I really don't want to spend
time on the board related patches like "x86: apl:".

> > P.S. Briefly looking at the last ~30 patches I can say that the idea
> > looks good, implementation needs more work. For example, there is
> > 'linux,name' property. Shouldn't be referred at all. Linux names and
> > other type of enumerations is utterly opaque to the outside world.
>
> How do we add the required linux,name ACPI property into the ACPI
> tables for a device?

There must not be Linux device names or anything Linux related (like
hardcoded GPIO numbers) in the ACPI table.

> > On top of that, I think we rather need to have a conversion layer than
> > putting some names inside DT, like \_SB_.GPO0 should be generated
> > automatically from DT node. That said, I don't like DT being polluted
> > with non-DT stuff.
>
> Well DT is the configuration mechanism for U-Boot.
>
> \_SB_.GPO0 is a special case since it actually refers to pinctrl (ACPI
> seems to make no distinction between pinctrl and GPIO) and this node
> is inside p2sb:
>
> pci {
>    p2sb at d,0 {
>       n {
>          gpio-n {
>
> So the automatically generated path would have p2sb in it. The same
> work-around is in coreboot.

It's not a coreboot, we may do better, right?
So, generation can strip p2sb (special case) from all p2sb devices.
However, I'm not sure I understand how p2sb is involved in GPIO
enumeration,

> > Also, I'm not sure how your rework helps ARM (or any other
> > architecture) people with their approach to ACPI enabling (most of the
> > files are under x86).
>
> I kept x86-specific tables in the x86 directories. Of course I might
> be wrong about this. But then, people who use ACPI on ARM (ick!)

Haven't you seen the series to introduce ACPI for ARM in U-Boot recently?

> probably have a better idea on what is needed. The core DM support and
> tests are there.

I think with a such big rework it's not big deal to simple move it
outside of arch/x86 to the lib/acpi or so.

-- 
With Best Regards,
Andy Shevchenko