Re: [PATCH] DMI: Decode and save OEM String information

I always thought that ACPI was supposed to describe everything that
(a) consumes resources or requires a driver and (b) is not enumerable
by other hardware standards such as PCI.

If that's true, isn't it a BIOS defect if this embedded controller isn't
described via ACPI?

The ThinkPad ACPI tables do list the relevant IO ports (0x1600-0x161F)
as reserved, but provide no way to discern what's behind them.

How are they listed? Maybe an example would help. Do you mean the
ACPI namespace has a device whose _CRS includes ports 0x1600-0x161F,
but that device's _HID is used for devices with different programming
models? Or do you mean it's in some static table (not the namespace)?
Or is the device at 0x1600-0x161F really a bridge, and we can't
determine what's on the other side?

BTW, I should clarify that this embedded controller interface (used by
hdaps and tp_smapi) is different than the standard ACPI EC interface,
and goes through different IO ports.

That's fine. The point is that for every device, ACPI should tell the
OS the programming model (with _HID/_CID) and resources it uses (with
_CRS/_PRS). If ACPI doesn't do that, how is the OS supposed to know
that it can't allocate those I/O ports to other devices?

it seems like the ideal way forward
would be to get the BIOS fixed so you could claim the device with PNP
for future ThinkPads, and the table of OEM strings would not require
ongoing maintenance.

This is unrealistic. The hdaps and tp_smapi drivers support dozens of
ThinkPad models, each with a different BIOS.

If there's an ACPI defect, I think it's realistic to report it and
ask for a fix in future releases. Obviously you can't fix all the
machines in the field, so you'd still need something like the OEM
string table. But if the BIOS were fixed for future machines, at
least the OEM string table would stop growing.