summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/dmi_scan.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'driver-core-6.10-rc1' of ↵Linus Torvalds2024-05-221-10/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the small set of driver core and kernfs changes for 6.10-rc1. Nothing major here at all, just a small set of changes for some driver core apis, and minor fixups. Included in here are: - sysfs_bin_attr_simple_read() helper added and used - device_show_string() helper added and used All usages of these were acked by the various maintainers. Also in here are: - kernfs minor cleanup - removed unused functions - typo fix in documentation - pay attention to sysfs_create_link() failures in module.c finally All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: device property: Fix a typo in the description of device_get_child_node_count() kernfs: mount: Remove unnecessary ‘NULL’ values from knparent scsi: Use device_show_string() helper for sysfs attributes platform/x86: Use device_show_string() helper for sysfs attributes perf: Use device_show_string() helper for sysfs attributes IB/qib: Use device_show_string() helper for sysfs attributes hwmon: Use device_show_string() helper for sysfs attributes driver core: Add device_show_string() helper for sysfs attributes treewide: Use sysfs_bin_attr_simple_read() helper sysfs: Add sysfs_bin_attr_simple_read() helper module: don't ignore sysfs_create_link() failures driver core: Remove unused platform_notify, platform_notify_remove
| * treewide: Use sysfs_bin_attr_simple_read() helperLukas Wunner2024-04-111-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deduplicate ->read() callbacks of bin_attributes which are backed by a simple buffer in memory: Use the newly introduced sysfs_bin_attr_simple_read() helper instead, either by referencing it directly or by declaring such bin_attributes with BIN_ATTR_SIMPLE_RO() or BIN_ATTR_SIMPLE_ADMIN_RO(). Aside from a reduction of LoC, this shaves off a few bytes from vmlinux (304 bytes on an x86_64 allyesconfig). No functional change intended. Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Zhi Wang <zhiwang@kernel.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/92ee0a0e83a5a3f3474845db6c8575297698933a.1712410202.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | firmware: dmi: Add info message for number of populated and total memory slotsHeiner Kallweit2024-05-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | As part of adding support for calling i2c_register_spd() on muxed SMBUS segments the same message has been removed from i2c_register_spd(). However users may find it useful, therefore reintroduce it as part of the DMI scan code. [JD: Static variable dmi_memdev_populated_nr is only used in __init functions, so it can be marked __initdata.] Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* | firmware: dmi: Stop decoding on broken entryJean Delvare2024-04-301-0/+11
|/ | | | | | | | | | If a DMI table entry is shorter than 4 bytes, it is invalid. Due to how DMI table parsing works, it is impossible to safely recover from such an error, so we have to stop decoding the table. Signed-off-by: Jean Delvare <jdelvare@suse.de> Link: https://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/ Reviewed-by: Michael Kelley <mhklinux@outlook.com>
* firmware: dmi: Fortify entry point length checksJean Delvare2022-09-231-2/+8
| | | | | | | | | | | | | | | | Ensure that the SMBIOS entry point is long enough to include all the fields we need. Otherwise it is pointless to even attempt to verify its checksum. Also fix the maximum length check, which is technically 32, not 31. It does not matter in practice as the only valid values are 31 (for SMBIOS 2.x) and 24 (for SMBIOS 3.x), but let's still have the check right in case new fields are added to either structure in the future. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/lkml/20220823094857.27f3d924@endymion.delvare/T/
* firmware: dmi: Use the proper accessor for the version fieldAndy Shevchenko2022-07-301-1/+1
| | | | | | | | | | The byte at offset 6 represents length. Don't take it and drop it immediately by using proper accessor, i.e. get_unaligned_be24(). [JD: Change the subject to something less frightening] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* ASoC: soc-core: fix DMI handlingPierre-Louis Bossart2021-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | When DMI information is not present, trying to assign the card long name results in the following warning. WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name! The initial solution suggested was to test if the card device is an ACPI one. This causes a regression visible to userspace on all Intel platforms, with UCM unable to load card profiles based on DMI information: the card devices are not necessarily ACPI ones, e.g. when the parent creates platform devices on Intel devices. To fix this problem, this patch exports the existing dmi_available variable and tests it in the ASoC core. Fixes: c014170408bc ("ASoC: soc-core: Prevent warning if no DMI table is present") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Acked-by: Jean Delvare <jdelvare@suse.de> Link: https://lore.kernel.org/r/20210310193928.108850-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Replace HTTP links with HTTPS ones: DMI/SMBIOS SUPPORTAlexander A. Klimov2020-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware/dmi: Report DMI Bios & EC firmware releaseErwan Velu2020-06-061-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some vendors like HPe or Dell, encode the release version of their BIOS in the "System BIOS {Major|Minor} Release" fields of Type 0. This information is used to know which bios release actually runs. It could be used for some quirks, debugging sessions or inventory tasks. A typical output for a Dell system running the 65.27 bios is : [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release 65.27 [root@t1700 ~]# Servers that have a BMC encode the release version of their firmware in the "Embedded Controller Firmware {Major|Minor} Release" fields of Type 0. This information is used to know which BMC release actually runs. It could be used for some quirks, debugging sessions or inventory tasks. A typical output for a Dell system running the 3.75 bmc release is : [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/ec_firmware_release 3.75 [root@t1700 ~]# Signed-off-by: Erwan Velu <e.velu@criteo.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi: Add macro SMBIOS_ENTRY_POINT_SCAN_STARTTiezhu Yang2020-03-231-1/+5
| | | | | | | | | | Use SMBIOS_ENTRY_POINT_SCAN_START instead of 0xF0000, because other archtecture maybe use a special start address such as 0xFFFE000 for Loongson platform. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
* firmware: dmi: Add dmi_memdev_handleJean Delvare2019-12-031-0/+16
| | | | | | | | Add a utility function dmi_memdev_handle() which returns the DMI handle associated with a given memory slot. This will allow kernel drivers to iterate over the memory slots. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi: Remember the memory typeJean Delvare2019-12-031-1/+24
| | | | | | | Store the memory type while walking the memory slots, and provide a way to retrieve it later. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi: Fix unlikely out-of-bounds read in save_mem_devicesJean Delvare2019-10-141-1/+1
| | | | | | | | | | | | | | Before reading the Extended Size field, we should ensure it fits in the DMI record. There is already a record length check but it does not cover that field. It would take a seriously corrupted DMI table to hit that bug, so no need to worry, but we should still fix it. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 6deae96b42eb ("firmware, DMI: Add function to look up a handle and return DIMM size") Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@suse.de>
* treewide: Add SPDX license identifier for missed filesThomas Gleixner2019-05-211-0/+1
| | | | | | | | | | | | | | | | | Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi: Unify DMI setup code over the arm/arm64, ia64 and x86 architecturesRobert Richter2019-03-291-13/+15
| | | | | | | | | | | | | | | | | | | | All architectures (arm/arm64, ia64 and x86) do the same here, so unify the code. Note: We do not need to call dump_stack_set_arch_desc() in case of !dmi_available. Both strings, dmi_ids_string and dump_stack_arch_ desc_str are initialized zero and thus nothing would change. Signed-off-by: Robert Richter <rrichter@marvell.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190328193429.21373-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
* mm: remove include/linux/bootmem.hMike Rapoport2018-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move remaining definitions and declarations from include/linux/bootmem.h into include/linux/memblock.h and remove the redundant header. The includes were replaced with the semantic patch below and then semi-automated removal of duplicated '#include <linux/memblock.h> @@ @@ - #include <linux/bootmem.h> + #include <linux/memblock.h> [sfr@canb.auug.org.au: dma-direct: fix up for the removal of linux/bootmem.h] Link: http://lkml.kernel.org/r/20181002185342.133d1680@canb.auug.org.au [sfr@canb.auug.org.au: powerpc: fix up for removal of linux/bootmem.h] Link: http://lkml.kernel.org/r/20181005161406.73ef8727@canb.auug.org.au [sfr@canb.auug.org.au: x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal] Link: http://lkml.kernel.org/r/20181008190341.5e396491@canb.auug.org.au Link: http://lkml.kernel.org/r/1536927045-23536-30-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Chris Zankel <chris@zankel.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Ingo Molnar <mingo@redhat.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ley Foon Tan <lftan@altera.com> Cc: Mark Salter <msalter@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Paul Burton <paul.burton@mips.com> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* firmware: dmi: Add access to the SKU ID stringSimon Glass2018-06-171-0/+1
| | | | | | | | | | | This is used in some systems from user space for determining the identity of the device. Expose this as a file so that that user-space tools don't need to read from /sys/firmware/dmi/tables/DMI Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Merge branch 'dmi-for-linus' of ↵Linus Torvalds2018-04-131-4/+12
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi updates from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi_scan: Use lowercase letters for UUID firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches firmware: dmi_scan: Fix UUID length safety check
| * firmware: dmi_scan: Use lowercase letters for UUIDJean Delvare2018-04-131-2/+2
| | | | | | | | | | | | | | | | | | | | RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this recommendation. Suggested by Paul Dagnelie at: https://savannah.nongnu.org/bugs/index.php?53569 Signed-off-by: Jean Delvare <jdelvare@suse.de>
| * firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matchesAlex Hung2018-04-131-1/+9
| | | | | | | | | | | | | | | | | | OEM strings are defined by each OEM and they contain customized and useful OEM information. Supporting it provides more flexible uses of the dmi_matches function. Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
| * firmware: dmi_scan: Fix UUID length safety checkJean Delvare2018-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The test which ensures that the DMI type 1 structure is long enough to hold the UUID is off by one. It would fail if the structure is exactly 24 bytes long, while that's sufficient to hold the UUID. I don't expect this bug to cause problem in practice because all implementations I have seen had length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length") Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | Merge tag 'edac_for_4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bpLinus Torvalds2018-04-051-0/+31
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull EDAC updates from Borislav Petkov: "Noteworthy is the NVDIMM support: - NVDIMM support to EDAC (Tony Luck) - misc fixes" * tag 'edac_for_4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp: EDAC, sb_edac: Remove variable length array usage EDAC, skx_edac: Detect non-volatile DIMMs firmware, DMI: Add function to look up a handle and return DIMM size acpi, nfit: Add function to look up nvdimm device and provide SMBIOS handle EDAC: Add new memory type for non-volatile DIMMs EDAC: Drop duplicated array of strings for memory type names EDAC, layerscape: Allow building for LS1021A
| * | firmware, DMI: Add function to look up a handle and return DIMM sizeTony Luck2018-03-141-0/+31
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we first scan the SMBIOS table, save the size of the DIMM. Provide a function for other code (EDAC driver) to look up the size of a DIMM from its SMBIOS handle. Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Tony Luck <tony.luck@intel.com> Cc: Aristeu Rozanski <aris@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: linux-acpi@vger.kernel.org Cc: linux-nvdimm@lists.01.org Link: http://lkml.kernel.org/r/20180312182430.10335-5-tony.luck@intel.com Signed-off-by: Borislav Petkov <bp@suse.de>
* / firmware/dmi_scan: Uninline dmi_get_bios_year() helperAndy Shevchenko2018-03-271-0/+20
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Uninline dmi_get_bios_year() which, in particular, allows us to optimize it in the future. While doing this, convert the function to return an error code when BIOS date is not present or not parsable, or CONFIG_DMI=n. Additionally, during the move, add a bit of documentation. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J . Wysocki <rjw@rjwysocki.net> Cc: linux-acpi@vger.kernel.org Cc: linux-pci@vger.kernel.org Fixes: 492a1abd61e4 ("dmi: Introduce the dmi_get_bios_year() helper function") Signed-off-by: Ingo Molnar <mingo@kernel.org>
* firmware: dmi: handle missing DMI data gracefullyArd Biesheuvel2018-02-031-4/+2
| | | | | | | | | | | | | | | | | | | | Currently, when booting a kernel with DMI support on a platform that has no DMI tables, the following output is emitted into the kernel log: [ 0.128818] DMI not present or invalid. ... [ 1.306659] dmi: Firmware registration failed. ... [ 2.908681] dmi-sysfs: dmi entry is absent. The first one is a pr_info(), but the subsequent ones are pr_err()s that complain about a condition that is not really an error to begin with. So let's clean this up, and give up silently if dma_available is not set. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Martin Hundebøll <mnhu@prevas.dk> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Fix handling of empty DMI stringsJean Delvare2018-02-031-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The handling of empty DMI strings looks quite broken to me: * Strings from 1 to 7 spaces are not considered empty. * True empty DMI strings (string index set to 0) are not considered empty, and result in allocating a 0-char string. * Strings with invalid index also result in allocating a 0-char string. * Strings starting with 8 spaces are all considered empty, even if non-space characters follow (sounds like a weird thing to do, but I have actually seen occurrences of this in DMI tables before.) * Strings which are considered empty are reported as 8 spaces, instead of being actually empty. Some of these issues are the result of an off-by-one error in memcmp, the rest is incorrect by design. So let's get it square: missing strings and strings made of only spaces, regardless of their length, should be treated as empty and no memory should be allocated for them. All other strings are non-empty and should be allocated. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 79da4721117f ("x86: fix DMI out of memory problems") Cc: Parag Warudkar <parag.warudkar@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de>
* firmware: dmi_scan: Drop dmi_initializedJean Delvare2018-02-031-13/+8
| | | | | | | | | | | | | | | | | I don't think it makes sense to check for a possible bad initialization order at run time on every system when it is all decided at build time. A more efficient way to make sure developers do not introduce new calls to dmi_check_system() too early in the initialization sequence is to simply document the expected call order. That way, developers have a chance to get it right immediately, without having to test-boot their kernel, wonder why it does not work, and parse the kernel logs for a warning message. And we get rid of the run-time performance penalty as a nice side effect. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Ingo Molnar <mingo@kernel.org>
* firmware: dmi: Optimize dmi_matchesJean Delvare2018-02-031-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Function dmi_matches can me made a bit faster: * The documented purpose of dmi_initialized is to catch too early calls to dmi_check_system(). I'm not fully convinced it justifies slowing down the initialization of all systems out there, but at least the check should not have been moved from dmi_check_system() to dmi_matches(). dmi_matches() is being called for every entry of the table passed to dmi_check_system(), causing the same redundant check to be performed again and again. So move it back to dmi_check_system(), reverting this specific portion of commit d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible"). * Don't check for the exact_match flag again when we already know its value. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Jeff Garzik <jgarzik@redhat.com>
* firmware: dmi_scan: Check DMI structure lengthJean Delvare2017-06-151-7/+16
| | | | | | | | | | | | Before accessing DMI data to record it for later, we should ensure that the DMI structures are large enough to contain the data in question. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org>
* firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codesAndy Lutomirski2017-06-151-4/+5
| | | | | | | | | Currently they return -1 on error, which will confuse callers if they try to interpret it as a normal negative error code. Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Look for SMBIOS 3 entry point firstJean Delvare2017-06-151-1/+16
| | | | | | | | | | | | | | | | | Since version 3.0.0 of the SMBIOS specification, there can be multiple entry points in memory, pointing to one or two DMI tables. If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry point are present, the specification requires that the latter points to a table which is a super-set of the table pointed to by the former. Therefore we should give preference to the 64-bit ("_SM3_") entry point. However, currently the code is picking the first valid entry point it finds. Per specification, we should look for a 64-bit ("_SM3_") entry point first, and if we can't find any, look for a 32-bit ("_SM_" or "_DMI_") entry point. Modify the code to do that. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi: Add DMI_PRODUCT_FAMILY identification stringMika Westerberg2017-05-231-0/+1
| | | | | | | | | | | | | | | Sometimes it is more convenient to be able to match a whole family of products, like in case of bunch of Chromebooks based on Intel_Strago to apply a driver quirk instead of quirking each machine one-by-one. This adds support for DMI_PRODUCT_FAMILY identification string and also exports it to the userspace through sysfs attribute just like the existing ones. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* firmware: dmi_scan: Always show system identification stringKefeng Wang2016-12-191-2/+2
| | | | | | | | | Let's keep consistent when print dmi_ids_string between SMBIOS 2.x and SMBIOS 3.x, and always show the system identification string, like Vendor, Product/Board name and BIOS infos. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Save SMBIOS Type 9 System SlotsJordan Hargrave2016-01-151-15/+36
| | | | | | | | Save SMBIOS Type 9 System Slots during DMI scan. PCI address of onboard devices was already saved but not for slots. Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Fix dmi_find_device descriptionJean Delvare2016-01-151-1/+1
| | | | | | | | | The description of dmi_find_device was apparently copied from a similar function in a different subsystem, but the parameter names were not adjusted as needed. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Andrey Panin <pazke@donpac.ru>
* firmware: dmi_scan: Clarify dmi_save_extended_devicesJean Delvare2016-01-151-6/+5
| | | | | | | | | Get rid of the arbitrary 5-byte pointer offset, it served no purpose and made it harder to match the code with the SMBIOS specification. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Jordan Hargrave <jordan_hargrave@dell.com> Cc: Narendra K <narendra_k@dell.com>
* firmware: dmi_scan: Optimize dmi_save_extended_devicesJean Delvare2016-01-151-2/+4
| | | | | | | | | Calling dmi_string_nosave isn't cheap, so avoid calling it twice in a row for the same string. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Jordan Hargrave <jordan_hargrave@dell.com> Cc: Narendra K <narendra_k@dell.com>
* firmware: dmi_scan: Fix UUID endianness for SMBIOS >= 2.6Andrea Arcangeli2016-01-081-3/+3
| | | | | | | | | | | | | | | The dmi_ver wasn't updated correctly before the dmi_decode method run to save the uuid. That resulted in "dmidecode -s system-uuid" and /sys/class/dmi/id/product_uuid disagreeing. The latter was buggy and this fixes it. Reported-by: Federico Simoncelli <fsimonce@redhat.com> Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()") Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Coding style cleanupsJean Delvare2015-06-251-4/+3
| | | | Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: add SBMIOS entry and DMI tablesIvan Khoronzhuk2015-06-251-0/+78
| | | | | | | | | | | | | | | | | | Some utils, like dmidecode and smbios, need to access SMBIOS entry table area in order to get information like SMBIOS version, size, etc. Currently it's done via /dev/mem. But for situation when /dev/mem usage is disabled, the utils have to use dmi sysfs instead, which doesn't represent SMBIOS entry and adds code/delay redundancy when direct access for table is needed. So this patch creates dmi/tables and adds SMBIOS entry point to allow utils in question to work correctly without /dev/mem. Also patch adds raw dmi table to simplify dmi table processing in user space, as proposed by Jean Delvare. Tested-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Trim DMI table length before exporting itJean Delvare2015-06-251-5/+10
| | | | | | | | | | | The SMBIOS v3 entry points specify a maximum length for the DMI table, not the exact length. Thus there may be garbage after the end-of-table marker, which we don't want to export to user-space. Adjust dmi_len when we find the end-of-table marker, so that only the actual table payload is exported. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
* firmware: dmi_scan: Rename dmi_table to dmi_decode_tableIvan Khoronzhuk2015-06-251-5/+5
| | | | | | | | | | The "dmi_table" function looks like data instance, but it does DMI table decode. This patch renames it to "dmi_decode_table" name as more appropriate. That allows us to use "dmi_table" name for correct purposes. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* firmware: dmi_scan: Only honor end-of-table for 64-bit tablesJean Delvare2015-06-251-4/+9
| | | | | | | | | | | | | | A 32-bit entry point to a DMI table says how many structures the table contains. The SMBIOS specification explicitly says that end-of-table markers should be ignored if they are not actually at the end of the DMI table. So only honor the end-of-table marker for tables accessed through 64-bit entry points, as they do not specify a structure count. Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point") Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Matt Fleming <matt.fleming@intel.com>
* firmware: dmi_scan: Fix ordering of product_uuidJean Delvare2015-05-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In function dmi_present(), dmi_walk_early() calls dmi_table(), which calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last function makes a decision based on the value of global variable dmi_ver. The problem is that this variable is set right _after_ dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0 regardless of the actual version implemented. This causes /sys/class/dmi/id/product_uuid to always use the old ordering even on systems implementing DMI/SMBIOS 2.6 or later, which should use the new ordering. This is broken since kernel v3.8 for legacy DMI implementations and since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3 implementations with the 64-bit entry point are not affected. The first breakage does not matter much as in practice legacy DMI implementations are always for versions older than 2.6, which is when the UUID ordering changed. The second breakage is more problematic as it affects the vast majority of x86 systems manufactured since 2009. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()") Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Artem Savkov <artem.savkov@gmail.com> Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Cc: Matt Fleming <matt.fleming@intel.com> Cc: stable@vger.kernel.org [v3.10+]
* firmware: dmi_scan: Simplified displayed versionJean Delvare2015-05-141-3/+2
| | | | | | | | | | | The trailing .x adds no information for the reader, and if anyone tries to parse that line, this is more work as they have 3 different formats to handle instead of 2. Plus, this makes backporting fixes harder. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 95be58df74a5 ("firmware: dmi_scan: Use full dmi version for SMBIOS3") Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
* Merge branch 'core-efi-for-linus' of ↵Linus Torvalds2015-04-131-17/+21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI update from Ingo Molnar: "This tree includes various fixes, cleanups, a new efi=debug boot option and EFI boot stub memory allocation optimizations" * 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub: Retrieve FDT size when loaded from UEFI config table efi: Clean up the efi_call_phys_[prolog|epilog]() save/restore interaction efi: Disable interrupts around EFI calls, not in the epilog/prolog calls x86/efi: Add a "debug" option to the efi= cmdline firmware: dmi_scan: Use direct access to static vars firmware: dmi_scan: Use full dmi version for SMBIOS3
| * firmware: dmi_scan: Use direct access to static varsIvan Khoronzhuk2015-03-261-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | There is no reason to pass static vars to function that can use only them. The dmi_table() can use only dmi_len and dmi_num static vars, so use them directly. In this case we can freely change their type in one place and slightly decrease redundancy. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| * firmware: dmi_scan: Use full dmi version for SMBIOS3Ivan Khoronzhuk2015-03-261-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New SMBIOS3 spec adds additional field for versioning - docrev. The docrev identifies the revision of a specification implemented in the table structures, so display SMBIOSv3 versions in format, like "3.22.1". In case of only 32 bit entry point for versions > 3 display dmi version like "3.22.x" as we don't know the docrev. In other cases display version like it was. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* | firmware: dmi_scan: Prevent dmi_num integer overflowJean Delvare2015-03-271-15/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | dmi_num is a u16, dmi_len is a u32, so this construct: dmi_num = dmi_len / 4; would result in an integer overflow for a DMI table larger than 256 kB. I've never see such a large table so far, but SMBIOS 3.0 makes it possible so maybe we'll see such tables in the future. So instead of faking a structure count when the entry point does not provide it, adjust the loop condition in dmi_table() to properly deal with the case where dmi_num is not set. This bug was introduced with the initial SMBIOS 3.0 support in commit fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point"). Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Cc: <stable@vger.kernel.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* firmware: dmi_scan: Fix dmi_len typeIvan Khoronzhuk2015-02-241-2/+2
| | | | | | | | | | | | | | | | According to SMBIOSv3 specification the length of DMI table can be up to 32bits wide. So use appropriate type to avoid overflow. It's obvious that dmi_num theoretically can be more than u16 also, so it's can be changed to u32 or at least it's better to use int instead of u16, but on that moment I cannot imagine dmi structure count more than 65535 and it can require changing type of vars that work with it. So I didn't correct it. Acked-by: Ard Biesheuvel <ard@linaro.org> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-15 07:05:23 +0000