linux/drivers/firmware/dmi_scan.c, branch v2.6.25

ipmi: change device node ordering to reflect probe order

2008-04-04T21:46:26Z

In 2.6.14 a patch was merged which switching the order of the ipmi device naming from in-order-of-discovery over to reverse-order-of-discovery. So on systems with multiple BMC interfaces, the ipmi device names are being created in reverse order relative to how they are discovered on the system (e.g. on an IBM x3950 multinode server with N nodes, the device name for the BMC in the first node is /dev/ipmiN-1 and the device name for the BMC in the last node is /dev/ipmi0, etc.). The problem is caused by the list handling routines chosen in dmi_scan.c. Using list_add() causes the multiple ipmi devices to be added to the device list using a stack-paradigm and so the ipmi driver subsequently pulls them off during initialization in LIFO order. This patch changes the dmi_save_ipmi_device() list handling paradigm to a queue, thereby allowing the ipmi driver to build the ipmi device names in the order in which they are found on the system. Signed-off-by: Carol Hebert Signed-off-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

dmi: prevent linked list corruption

2008-02-24T01:12:15Z

Adding the same item to a given linked list more than once is guaranteed to break and corrupt the list. This is however what we do in dmi_scan since commit 79da4721117fcf188b4b007b775738a530f574da ("x86: fix DMI out of memory problems"). Given that there is absolutely no interest in saving empty OEM strings anyway, I propose the simple and efficient fix below: we discard the empty OEM strings altogether. Signed-off-by: Jean Delvare Acked-by: Parag Warudkar Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Matt Domsch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

dmi: don't save the same device twice

2008-02-24T01:12:14Z

Now that we gather on-board devices from both DMI types 10 and 41, there is a possibility that we list the same device twice. In order to not confuse drivers, and also to save memory, make sure that we do not add duplicate devices to the dmi_devices list. Signed-off-by: Jean Delvare Cc: Wim Van Sebroeck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

SMBIOS/DMI: add type 41 = Onboard Devices Extended Information

2008-02-08T17:22:37Z

From version 2.6 of the SMBIOS standard, type 10 (On Board Devices Information) becomes obsolete. The reason for this is that no further fields can be added to this structure without adversely affecting existing software's ability to properly parse the data. Therefore type 41 (Onboard Devices Extended Information) was added. The structure is as follows: struct smbios_type_41 { u8 type; u8 length; u16 handle; u8 reference_designation_string; u8 device_type; /* same device type as in type 10 */ u8 device_type_instance; u16 segment_group_number; u8 bus_number; u8 device_function_number; }; For more info: http://www.dmtf.org/standards/smbios Signed-off-by: Wim Van Sebroeck Cc: Jean Delvare Cc: Len Brown Cc: Jeff Garzik Cc: Tejun Heo Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

dmi: Let drivers walk the DMI table

2008-02-08T01:39:40Z

Let drivers walk the DMI table for their own needs. Some drivers need data stored in OEM-specific DMI records for proper operation. Signed-off-by: Jean Delvare Signed-off-by: Mark M. Hoffman

DMI: remove duplicate helper routine

2008-02-03T22:37:02Z

Use existing dmi_get_system_info(), Delete duplicate dmi_get_slot() Spotted-by: Wim Van Sebroeck Signed-off-by: Len Brown

x86: left over fix for leak of early_ioremp in dmi_scan

2008-01-30T12:33:32Z

Signed-off-by: Yinghai Lu Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: fix DMI ioremap leak

2008-01-30T12:33:09Z

Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: fix DMI out of memory problems

2008-01-30T12:31:59Z

People with HP Desktops (including me) encounter couple of DMI errors during boot - dmi_save_oem_strings_devices: out of memory and dmi_string: out of memory. On some HP desktops the DMI data include OEM strings (type 11) out of which only few are meaningful and most other are empty. DMI code religiously creates copies of these 27 strings (65 bytes each in my case) and goes OOM in dmi_string(). If DMI_MAX_DATA is bumped up a little then it goes and fails in dmi_save_oem_strings while allocating dmi_devices of sizeof(struct dmi_device) corresponding to these strings. On x86_64 since we cannot use alloc_bootmem this early, the code uses a static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI needs. It does not survive the creation of empty strings and devices. Fix this by detecting and not newly allocating empty strings and instead using a one statically defined dmi_empty_string. Also do not create a new struct dmi_device for each empty string - use one statically define dmi_device with .name=dmi_empty_string and add that to the dmi_devices list. On x64 this should stop the OOM with same current size of DMI_MAX_DATA and on x86 this should save a good amount of (27*65 bytes + 27*sizeof(struct dmi_device) bootmem. Compile and boot tested on both 32-bit and 64-bit x86. Signed-off-by: Parag Warudkar Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

DMI: create dmi_get_slot()

2008-01-24T02:23:13Z

This simply allows other sub-systems (such as ACPI) to access and print out slots in static dmi_ident[]. Signed-off-by: Len Brown