From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934902AbcHaOB3 (ORCPT ); Wed, 31 Aug 2016 10:01:29 -0400 Received: from esa7.dell-outbound.iphmx.com ([68.232.153.96]:29706 "EHLO esa7.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934044AbcHaOB0 (ORCPT ); Wed, 31 Aug 2016 10:01:26 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:Received:X-LoopCount0:X-IronPort-AV:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path; b=qG36g+57lRXunnTY5aEDhqVIuCcbsSZ1OIpkPxkIO/JRPzr0lYU7cLxT r0RwV6dQhuGeI4LQq1drPjqJ0TQW211hj0yr8ifZdqdboFG9YHCLg2fv4 KbfYxDcVAHMJXwW7kkoozTPAb23t6i7bam0HZ+MMmJNjW/PFAECrjg1Df 8=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.30,262,1470718800"; d="scan'208";a="363016161" From: To: , CC: , , , , , , , , , Subject: RE: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs Thread-Topic: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs Thread-Index: AQHR9tavG5pByOTFLUi7GvOG9yHjLaBjb7kA//+/MDA= Date: Wed, 31 Aug 2016 14:01:23 +0000 Message-ID: <488533a5959a46eca5f037cca26f42bd@ausx13mpc124.AMER.DELL.COM> References: <1471252925-8082-1-git-send-email-allen_hung@dell.com> <20160831124002.GA26534@kroah.com> In-Reply-To: <20160831124002.GA26534@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.69.211] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7VE1YMu004951 Hi Greg, > -----Original Message----- > From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org] > Sent: Wednesday, August 31, 2016 7:40 AM > To: Hung, Allen > Cc: Jean Delvare ; Russell King > ; Gabriel Somlo ; Bjorn > Andersson ; Jens Wiklander > ; Andy Gross ; Arnd > Bergmann ; Sudeep Holla ; Eric > Anholt ; linux-kernel@vger.kernel.org; Limonciello, Mario > > 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 > > --- > > 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.