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

Powered by blists - more mailing lists