[PATCH] DMI: Decode and save OEM String information

[PATCH] DMI: Decode and save OEM String information

[Shem Multinymous]

This teachs dmi_decode() how to to save OEM Strings (type 11) information.
OEM Strings are  the only safe way to identify some hardware, e.g., the ThinkPad
embedded controller used by the soon-to-be-submitted tp_smapi driver.

Follows the "System Management BIOS (SMBIOS) Specification"
(http://www.dmtf.org/standards/smbios), and also the userspace
dmidecode.c code.

---
 drivers/firmware/dmi_scan.c |   21 +++++++++++++++++++++
 include/linux/dmi.h         |    3 ++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index b9e3886..d1add3f 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -123,6 +123,24 @@ static void __init dmi_save_devices(stru
 		dev->type = *d++ & 0x7f;
 		dev->name = dmi_string(dm, *d);
 		dev->device_data = NULL;
+		list_add(&dev->list, &dmi_devices);
+	}
+}
+
+static void __init dmi_save_oem_strings_devices(struct dmi_header *dm)
+{
+	int i, count = *(u8 *)(dm + 1);
+	struct dmi_device *dev;
+
+	for (i = 1; i <= count; i++) {
+		dev = dmi_alloc(sizeof(*dev));
+		if (!dev) {
+			break;
+		}
+
+		dev->type = DMI_DEV_TYPE_OEM_STRING;
+		dev->name = dmi_string(dm, i);
+		dev->device_data = NULL;

 		list_add(&dev->list, &dmi_devices);
 	}
@@ -181,6 +199,9 @@ static void __init dmi_decode(struct dmi
 	case 10:	/* Onboard Devices Information */
 		dmi_save_devices(dm);
 		break;
+	case 11:	/* OEM Strings */
+		dmi_save_oem_strings_devices(dm);
+		break;
 	case 38:	/* IPMI Device Information */
 		dmi_save_ipmi_device(dm);
 	}
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index b2cd207..38dc403 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -27,7 +27,8 @@ enum dmi_device_type {
 	DMI_DEV_TYPE_ETHERNET,
 	DMI_DEV_TYPE_TOKENRING,
 	DMI_DEV_TYPE_SOUND,
-	DMI_DEV_TYPE_IPMI = -1
+	DMI_DEV_TYPE_IPMI = -1,
+	DMI_DEV_TYPE_OEM_STRING = -2
 };

 struct dmi_header {

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

[Bjorn Helgaas]

On Thursday 27 July 2006 07:47, Shem Multinymous wrote:
> This teachs dmi_decode() how to to save OEM Strings (type 11) information.
> OEM Strings are  the only safe way to identify some hardware, e.g., the ThinkPad
> embedded controller used by the soon-to-be-submitted tp_smapi driver.

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?

I don't object to this patch, but 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.

> Follows the "System Management BIOS (SMBIOS) Specification"
> (http://www.dmtf.org/standards/smbios), and also the userspace
> dmidecode.c code.
> 
> ---
>  drivers/firmware/dmi_scan.c |   21 +++++++++++++++++++++
>  include/linux/dmi.h         |    3 ++-
>  2 files changed, 23 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index b9e3886..d1add3f 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -123,6 +123,24 @@ static void __init dmi_save_devices(stru
>  		dev->type = *d++ & 0x7f;
>  		dev->name = dmi_string(dm, *d);
>  		dev->device_data = NULL;
> +		list_add(&dev->list, &dmi_devices);
> +	}
> +}
> +
> +static void __init dmi_save_oem_strings_devices(struct dmi_header *dm)
> +{
> +	int i, count = *(u8 *)(dm + 1);
> +	struct dmi_device *dev;
> +
> +	for (i = 1; i <= count; i++) {
> +		dev = dmi_alloc(sizeof(*dev));
> +		if (!dev) {
> +			break;
> +		}
> +
> +		dev->type = DMI_DEV_TYPE_OEM_STRING;
> +		dev->name = dmi_string(dm, i);
> +		dev->device_data = NULL;
> 
>  		list_add(&dev->list, &dmi_devices);
>  	}
> @@ -181,6 +199,9 @@ static void __init dmi_decode(struct dmi
>  	case 10:	/* Onboard Devices Information */
>  		dmi_save_devices(dm);
>  		break;
> +	case 11:	/* OEM Strings */
> +		dmi_save_oem_strings_devices(dm);
> +		break;
>  	case 38:	/* IPMI Device Information */
>  		dmi_save_ipmi_device(dm);
>  	}
> diff --git a/include/linux/dmi.h b/include/linux/dmi.h
> index b2cd207..38dc403 100644
> --- a/include/linux/dmi.h
> +++ b/include/linux/dmi.h
> @@ -27,7 +27,8 @@ enum dmi_device_type {
>  	DMI_DEV_TYPE_ETHERNET,
>  	DMI_DEV_TYPE_TOKENRING,
>  	DMI_DEV_TYPE_SOUND,
> -	DMI_DEV_TYPE_IPMI = -1
> +	DMI_DEV_TYPE_IPMI = -1,
> +	DMI_DEV_TYPE_OEM_STRING = -2
>  };
> 
>  struct dmi_header {
> 

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

[Shem Multinymous]

Hi,

On 7/27/06, Bjorn Helgaas <bjorn.helgaas@hp.com> 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. Other
machines have different hardware on the same ports.

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.


> 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.

For the tp_smapi driver, AFAIK the only completely safe alternative to
this patch is a frequently-updated whitelist of over a hundred models,
identified by the existing DMI attributes.

  Shem

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

[Bjorn Helgaas]

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

Bjorn

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

[Henrique de Moraes Holschuh]

On Thu, 27 Jul 2006, Bjorn Helgaas wrote:
> > > 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

In the T43, very recent BIOS, it is inside _SB_.PCI0.LPC.SIO, where _HID is
PNP0C02, and it holds resources to a number of different devices.  Port 1600
is not even in a block by itself, it is in a block that reserves 0x42 bytes,
while the EC occupies just 0x1600-0x161F.

> 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?

Tell that to the vendors...

> > > 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

I very much doubt you can pull that off, but if anyone has good contacts
within IBM/Lenovo's ThinkPad notebook division, we could try.  Heck, the
Thinkpad community have *firmware* fixes to send them and no channel
whatsoever to send a report to engineering.  Lenovo support doesn't let you
report something like that, unlike, say, Intel's.

> 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.

The table (within the driver, for whitelisting) has exactly *one* substring
for string match, that works for all models since the A31, and maybe even
earlier ones.  The OEM string table used by IBM is quite stable.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

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

[Bjorn Helgaas]

On Friday 28 July 2006 06:49, Henrique de Moraes Holschuh wrote:
> On Thu, 27 Jul 2006, Bjorn Helgaas wrote:
> > > > 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
> 
> In the T43, very recent BIOS, it is inside _SB_.PCI0.LPC.SIO, where _HID is
> PNP0C02, and it holds resources to a number of different devices.  Port 1600
> is not even in a block by itself, it is in a block that reserves 0x42 bytes,
> while the EC occupies just 0x1600-0x161F.

And there are no other devices that consume 0x1600-0x161F?  Interesting.
I wonder what Windows does to bind drivers to the LPC devices?  Do they
have to do the same SMBIOS OEM string hack?

> The table (within the driver, for whitelisting) has exactly *one* substring
> for string match, that works for all models since the A31, and maybe even
> earlier ones.  The OEM string table used by IBM is quite stable.

I guess as long as they change the OEM string the same time they change
the EC/accelerometer/battery/kitchen-sink implementation, you're OK :-)
It just feels like living on borrowed time.

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

[Shem Multinymous]

On 7/28/06, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> And there are no other devices that consume 0x1600-0x161F?  Interesting.
> I wonder what Windows does to bind drivers to the LPC devices?  Do they
> have to do the same SMBIOS OEM string hack?

We don't know. Maybe they check the ThinkPad part number (of which
there are many hundreds but IBM/Lenovo has the full list and can
update the driver whenever a new model comes out); or maybe just
assume you won't install it on the wrong hardware.


> I guess as long as they change the OEM string the same time they change
> the EC/accelerometer/battery/kitchen-sink implementation, you're OK :-)
> It just feels like living on borrowed time.

Yes. But it's the best we've been able to come up with, after
considerable community effort.

Anyway, this patch is independent of the ThinkPad case; DMI
information is there for drivers to see it, after all, so the kernel
should make it possible. Can I get a Signed-off-by?

  Shem

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

[Bjorn Helgaas]

On Friday 28 July 2006 14:52, Shem Multinymous wrote:
> Anyway, this patch is independent of the ThinkPad case; DMI
> information is there for drivers to see it, after all, so the kernel
> should make it possible. Can I get a Signed-off-by?

If you're the author, you're the one to supply the "Signed-off-by";
see Documentation/SubmittingPatches for exactly what it means.

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

[Shem Multinymous]

(Going off lists)

On 7/29/06, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Friday 28 July 2006 14:52, Shem Multinymous wrote:
> > Anyway, this patch is independent of the ThinkPad case; DMI
> > information is there for drivers to see it, after all, so the kernel
> > should make it possible. Can I get a Signed-off-by?
>
> If you're the author, you're the one to supply the "Signed-off-by";
> see Documentation/SubmittingPatches for exactly what it means.

Sorry, I misunderstood the protocol. I guess I'm asking for an
Acked-by, except I don't see that one mentioned in Documentation/*.

Anyway, if there are no more comments I'll repost with the missing
"Signed-off-by: Shem Multinymous <multinymous@gmail.com>".

  Shem

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

[Shem Multinymous]

This teaches dmi_decode() how to decode and save OEM Strings (type 11)
DMI information, which is currently discarded silently. Existing code
using DMI is not affected. Follows the "System Management BIOS
(SMBIOS) Specification" (http://www.dmtf.org/standards/smbios),
and also the userspace dmidecode.c code.

OEM Strings are the only safe way to identify some hardware, e.g., the
ThinkPad embedded controller used by the soon-to-be-submitted tp_smapi
driver. This will also let us eliminate the long whitelist in the mainline
hdaps driver (in a future patch).

Signed-off-by: Shem Multinymous <multinymous@gmail.com>
---
Reposting with better error handling, improved description and a
Signed-off-by.

If there's any problem with acceptance please let me know, since
I'm working on additional patches that will depend on this DMI
information.

To test this patch, run the following kernel code after boot:
	#include <linux/dmi.h>
	...
	struct dmi_device *dev = NULL;
	while ((dev = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, NULL, dev))) {
		printk(KERN_DEBUG "DMI OEM string: '%s'\n", dev->name);
	}
This will printk all DMI OEM strings (if any), so you can compare it to
# dmidecode | grep -A5 'OEM Strings'


 drivers/firmware/dmi_scan.c |   23 +++++++++++++++++++++++
 include/linux/dmi.h         |    3 ++-
 2 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index b9e3886..04f1597 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -123,6 +123,26 @@ static void __init dmi_save_devices(stru
 		dev->type = *d++ & 0x7f;
 		dev->name = dmi_string(dm, *d);
 		dev->device_data = NULL;
+		list_add(&dev->list, &dmi_devices);
+	}
+}
+
+static void __init dmi_save_oem_strings_devices(struct dmi_header *dm)
+{
+	int i, count = *(u8 *)(dm + 1);
+	struct dmi_device *dev;
+
+	for (i = 1; i <= count; i++) {
+		dev = dmi_alloc(sizeof(*dev));
+		if (!dev) {
+			printk(KERN_ERR
+			   "dmi_save_oem_strings_devices: out of memory.\n");
+			break;
+		}
+
+		dev->type = DMI_DEV_TYPE_OEM_STRING;
+		dev->name = dmi_string(dm, i);
+		dev->device_data = NULL;

 		list_add(&dev->list, &dmi_devices);
 	}
@@ -181,6 +201,9 @@ static void __init dmi_decode(struct dmi
 	case 10:	/* Onboard Devices Information */
 		dmi_save_devices(dm);
 		break;
+	case 11:	/* OEM Strings */
+		dmi_save_oem_strings_devices(dm);
+		break;
 	case 38:	/* IPMI Device Information */
 		dmi_save_ipmi_device(dm);
 	}
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index b2cd207..38dc403 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -27,7 +27,8 @@ enum dmi_device_type {
 	DMI_DEV_TYPE_ETHERNET,
 	DMI_DEV_TYPE_TOKENRING,
 	DMI_DEV_TYPE_SOUND,
-	DMI_DEV_TYPE_IPMI = -1
+	DMI_DEV_TYPE_IPMI = -1,
+	DMI_DEV_TYPE_OEM_STRING = -2
 };

 struct dmi_header {

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

[Carl-Daniel U. Hailfinger]

Hi!

Shem Multinymous wrote:
> 
> Signed-off-by: Shem Multinymous <multinymous@gmail.com>

I can't help but notice that you have an interesting name which sounds a bit "synthetic" to me (no offense). IIRC some time ago it was stated that the Signed-off-by line should contain a real name. If that is really your name, I wish to apologize.

Regards,
Carl-Daniel
-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl

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

[Shem Multinymous]

On 7/29/06, Carl-Daniel U. Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
> I can't help but notice that you have an interesting name which sounds a bit
> "synthetic" to me (no offense). IIRC some time ago it was stated that the
> Signed-off-by line should contain a real name. If that is really your name, I wish to
> apologize.

I own the legal rights to this patch [1] and offer it under the GPL.
This name and e-mail identify me uniquely, and form reliable contact
address. Google my work on tp_smapi if you have doubts about this.
What more do you need?

  Shem

[1] Apart from the copyright on the mainline kernel source it
modifies, of course, and maybe dmidecode's dmidecode.c; both are
GPLed.

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

[Pavel Machek]

Hi!

> > Signed-off-by: Shem Multinymous <multinymous@gmail.com>
> 
> I can't help but notice that you have an interesting name which sounds a bit "synthetic" to me (no offense). IIRC some time ago it was stated that the Signed-off-by line should contain a real name. If that is really your name, I wish to apologize.

If that's a problem, I can sign off for that patch. Its author is
providing it under GPL, so I can do it.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

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

[Pavel Machek]

Hi!

> This teachs dmi_decode() how to to save OEM Strings 
> (type 11) information.
> OEM Strings are  the only safe way to identify some 
> hardware, e.g., the ThinkPad
> embedded controller used by the soon-to-be-submitted 
> tp_smapi driver.
> 
> Follows the "System Management BIOS (SMBIOS) 
> Specification"
> (http://www.dmtf.org/standards/smbios), and also the 
> userspace
> dmidecode.c code.

Looks good to me.

							Pavel
-- 
Thanks for all the (sleeping) penguins.