[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <488533a5959a46eca5f037cca26f42bd@ausx13mpc124.AMER.DELL.COM>
Date: Wed, 31 Aug 2016 14:01:23 +0000
From: <Mario_Limonciello@...l.com>
To: <gregkh@...uxfoundation.org>, <Allen_Hung@...l.com>
CC: <jdelvare@...e.com>, <rmk+kernel@....linux.org.uk>,
<somlo@....edu>, <bjorn.andersson@...ymobile.com>,
<jens.wiklander@...aro.org>, <agross@...eaurora.org>,
<arnd@...db.de>, <sudeep.holla@....com>, <eric@...olt.net>,
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem
strings to sysfs
Hi Greg,
> -----Original Message-----
> From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
> Sent: Wednesday, August 31, 2016 7:40 AM
> To: Hung, Allen <Allen_Hung@...l.com>
> Cc: Jean Delvare <jdelvare@...e.com>; Russell King
> <rmk+kernel@....linux.org.uk>; Gabriel Somlo <somlo@....edu>; Bjorn
> Andersson <bjorn.andersson@...ymobile.com>; Jens Wiklander
> <jens.wiklander@...aro.org>; Andy Gross <agross@...eaurora.org>; Arnd
> Bergmann <arnd@...db.de>; Sudeep Holla <sudeep.holla@....com>; Eric
> Anholt <eric@...olt.net>; linux-kernel@...r.kernel.org; Limonciello, Mario
> <Mario_Limonciello@...l.com>
> Subject: Re: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem
> strings to sysfs
>
> On Mon, Aug 15, 2016 at 05:22:05PM +0800, Allen Hung wrote:
> > The oem strings in DMI system identification information of the BIOS
> > have been parsed and stored as dmi devices in dmi_scan.c but they are
> > not exported to userspace via sysfs.
> >
> > The patch intends to export oem strings to sysfs device /sys/class/dmi/id.
> > As the number of oem strings are dynamic, a group "oem" is added to
> > the device and the strings will be added to the group as string1,
> > string2, ..., and stringN.
> >
> > Signed-off-by: Allen Hung <allen_hung@...l.com>
> > ---
> > drivers/firmware/Kconfig | 9 ++++
> > drivers/firmware/dmi-id.c | 116
> > ++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 125 insertions(+)
> >
> > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index
> > 6664f11..885a6c9 100644
> > --- a/drivers/firmware/Kconfig
> > +++ b/drivers/firmware/Kconfig
> > @@ -119,6 +119,15 @@ config DMIID
> > information from userspace through /sys/class/dmi/id/ or if you want
> > DMI-based module auto-loading.
> >
> > +config DMIID_OEM_STRINGS
> > + bool "Export OEM strings in SMBIOS/DMI via sysfs to userspace"
> > + depends on DMIID
> > + default n
> > + help
> > + Say Y here if you want to query OEM strings (as part of the information
> > + contained in SMBIOS/DMI system identification) from userspace
> through
> > + /sys/class/dmi/id/oem/.
>
> Why wouldn't you want these?
>
Jean Delvare would rather see this implemented in userspace dmidecode.
Jean raised a concern in an earlier submission that this runs on every
machine (https://lkml.org/lkml/2016/8/2/799).
> > +
> > config DMI_SYSFS
> > tristate "DMI table support in sysfs"
> > depends on SYSFS && DMI
>
> Shouldn't the new option, if you really want it, be below this one?
>
Ah yes, I think so. If this ends up being the right approach Allen
will need to adjust and resubmit it.
> But again, why not just always provide these values, if they are in the DMI
> tables, and you want sysfs DMI support?
>From our (Allen and myself) perspective this makes the most sense too,
Jean had pushed back on this, so Allen re-submitted as making it optional.
Powered by blists - more mailing lists