netdev - Re: [PATCH] Export smbios strings associated with onboard devices to sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Mar 2010 10:38:38 -0700
From:	Alex Chiang <achiang@...com>
To:	Narendra K <Narendra_K@...l.com>
Cc:	matt_domsch@...l.com, netdev@...r.kernel.org,
	linux-hotplug@...r.kernel.org, linux-pci@...r.kernel.org,
	jordan_hargrave@...l.com, sandeep_k_shandilya@...l.com,
	charles_rose@...l.com, shyam_iyer@...l.com
Subject: Re: [PATCH] Export smbios strings associated with onboard devices
	to sysfs

* Narendra K <Narendra_K@...l.com>:
> 
> Resending the patch with review comments incorporated.
> 
> Signed-off-by: Jordan Hargrave <Jordan_Hargrave@...l.com>
> Signed-off-by: Narendra K <Narendra_K@...l.com>

Here is a patch I wrote that would be nice if you could
incorporate into your patch series.

It adds support for HP OEM SMBIOS record Type 209, so that you
can populate the 'label' attribute on existing HP platforms.

It needs that hunk I suggested in my previous mail to apply
cleanly.

Thanks,
/ac

From: Alex Chiang <achiang@...com>

dmi: save OEM defined slot information

Some legacy platforms provide onboard device information in an SMBIOS
OEM-defined field, notably HP Proliants.

This information can be used to provide information to userspace that
allows correlation between a Linux PCI device and a chassis label.

Save this information so that it can be exposed to userspace. We choose
the string "Embedded NIC %d" since there are known platforms from other
vendors (Dell) that provide a string in this format for their onboard
NICs (although theirs is provided by a Type 41 record). This consistency
will help simplify life for userspace tools.

Only support HP platforms for now. If we need support for another vendor
in the future, we can write a fancier implementation then.

This code was inspired by the implementation in the userspace dmidecode
tool, which was originally written by John Cagle.

Signed-off-by: Alex Chiang <achiang@...com>
---
 dmi_scan.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
---
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 5a81a8b..cb2a57a 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -314,6 +314,33 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
 	dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
 }

+static void __init dmi_save_oem_devices(const struct dmi_header *dm)
+{
+	int bus, devfn, count;
+	const u8 *d = (u8 *)dm + 4;
+	char name[20];
+
+	/* Only handle HP extensions for now */
+	if (strcmp(dmi_ident[DMI_BIOS_VENDOR], "HP"))
+		return;
+
+	count = 1;
+	while ((d + 8) <= ((u8 *)dm + dm->length)) {
+		if ((*d == 0x00 && *(d + 1) == 0x00) ||
+		    (*d == 0xff && *(d + 1) == 0xff))
+			goto next;
+
+		bus = *(d + 1);
+		devfn = *d;
+		sprintf(name, "Embedded NIC %d", count);
+		dmi_save_devslot(-1, 0, bus, devfn, name);
+
+next:
+		count++;
+		d += 8;
+	}
+}
+
 /*
  *	Process a DMI table entry. Right now all we care about are the BIOS
  *	and machine entries. For 2.5 we should pull the smbus controller info
@@ -360,6 +387,9 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
 	case 41:	/* Onboard Devices Extended Information */
 		dmi_save_extended_devices(dm);
 		break;
+	case 209:
+		dmi_save_oem_devices(dm);
+		break;
 	}
 }

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html