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

On Thursday 27 July 2006 10:42, Shem Multinymous wrote:
On 7/27/06, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at

Relevant Pages

  • Re: FreeBSD 6.1-STABLE: Unexplained power off
    ... playing with BIOS and kernel options. ... I can only disable some ACPI ... <ACPI PCI bus> on pcib0 ... 2 ports with 2 removable, ...
  • Re: 2.6.25-rc1 ahci regression
    ... AMI BIOS detected: BIOS may corrupt low RAM, ... ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! ... pcieport 0000:00:01.0: Requesting control of PCIe PME from ACPI BIOS ... 8250/16550 driver, 4 ports, IRQ sharing enabled ...
  • Re: Duplicate COM ports
    ... The BIOS ... does not have a disable-ACPI capability. ... still seeing the duplicate ports. ... >Sounds like an ACPI issue to me. ...
  • Re: Duplicate COM ports
    ... The BIOS ... > does not have a disable-ACPI capability. ... > its installation and the BIOS is not ACPI, ... > still seeing the duplicate ports. ...
  • OOPS in, connected to nfs4 and autofs4
    ... ACPI: Local APIC address 0xfee00000 ... Linux Plug and Play Support v0.97 Adam Belay ... USB Universal Host Controller Interface driver v3.0 ... hub 1-0:1.0: 2 ports detected ...