From: Jean Delvare <jdelvare@suse.de>
To: Erwan Velu <erwanaliasr1@gmail.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>,
Erwan Velu <e.velu@criteo.com>,
"David S. Miller" <davem@davemloft.net>,
Changbin Du <changbin.du@intel.com>,
Boris Brezillon <bbrezillon@kernel.org>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Sumit Garg <sumit.garg@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Michal Marek <michal.lkml@markovi.net>,
Mattias Jacobsson <2pi@mok.nu>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] firmware/dmi: Report DMI Bios release
Date: Mon, 21 Oct 2019 16:53:21 +0200 [thread overview]
Message-ID: <20191021165321.60be88cd@endymion> (raw)
In-Reply-To: <20190918094323.17515-2-e.velu@criteo.com>
On Wed, 18 Sep 2019 11:43:20 +0200, Erwan Velu wrote:
> Some vendors like HPe or Dell, encodes the release version of their BIOS
encodes -> encode
> in the "System BIOS {Major|Minor} Release" fields of Type 0.
>
> This information is useful to know which release of the bios is actually running.
> It could be used for some quirks, debugging sessions or inventory tasks.
>
> This patch extract these 2 fields in DMI_BIOS_MAJOR_RELEASE & DMI_BIOS_MINOR_RELEASE.
>
> A typical output for a Dell system running the 65.27 bios is :
>
> [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release_major
> 65
> [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release_minor
> 27
> [root@t1700 ~]#
I don't think we want two fields. This adds quite some overhead, and
they are not independent from each other anyway. I'd rather have one
field with the values combined:
[root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release
65.27
[root@t1700 ~]#
This would also be in line with how it was implemented in dmidecode. Is
there any reason to NOT go that route?
--
Jean Delvare
SUSE L3 Support
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <jdelvare@suse.de>
To: "Erwan Velu" <erwanaliasr1@gmail.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>,
"Erwan Velu" <e.velu@criteo.com>,
"David S. Miller" <davem@davemloft.net>,
"Changbin Du" <changbin.du@intel.com>,
"Boris Brezillon" <bbrezillon@kernel.org>,
"Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
"Sumit Garg" <sumit.garg@linaro.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Michal Marek" <michal.lkml@markovi.net>,
"Mattias Jacobsson" <2pi@mok.nu>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
<linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] firmware/dmi: Report DMI Bios release
Date: Mon, 21 Oct 2019 16:53:21 +0200 [thread overview]
Message-ID: <20191021165321.60be88cd@endymion> (raw)
In-Reply-To: <20190918094323.17515-2-e.velu@criteo.com>
On Wed, 18 Sep 2019 11:43:20 +0200, Erwan Velu wrote:
> Some vendors like HPe or Dell, encodes the release version of their BIOS
encodes -> encode
> in the "System BIOS {Major|Minor} Release" fields of Type 0.
>
> This information is useful to know which release of the bios is actually running.
> It could be used for some quirks, debugging sessions or inventory tasks.
>
> This patch extract these 2 fields in DMI_BIOS_MAJOR_RELEASE & DMI_BIOS_MINOR_RELEASE.
>
> A typical output for a Dell system running the 65.27 bios is :
>
> [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release_major
> 65
> [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release_minor
> 27
> [root@t1700 ~]#
I don't think we want two fields. This adds quite some overhead, and
they are not independent from each other anyway. I'd rather have one
field with the values combined:
[root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release
65.27
[root@t1700 ~]#
This would also be in line with how it was implemented in dmidecode. Is
there any reason to NOT go that route?
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2019-10-21 14:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 9:43 [PATCH 1/3] firmware/dmi_scan: Add dmi_save_release to save releases fields Erwan Velu
2019-09-18 9:43 ` Erwan Velu
2019-09-18 9:43 ` [PATCH 2/3] firmware/dmi: Report DMI Bios release Erwan Velu
2019-09-18 9:43 ` Erwan Velu
2019-10-21 14:53 ` Jean Delvare [this message]
2019-10-21 14:53 ` Jean Delvare
2019-11-27 15:05 ` Erwan Velu
2019-09-18 9:43 ` [PATCH 3/3] firmware/dmi: Report DMI Embedded Firmware release Erwan Velu
2019-09-18 9:43 ` Erwan Velu
2019-10-21 14:55 ` Jean Delvare
2019-10-21 14:55 ` Jean Delvare
2019-10-21 14:32 ` [PATCH 1/3] firmware/dmi_scan: Add dmi_save_release to save releases fields Jean Delvare
2019-10-21 14:32 ` Jean Delvare
2019-11-27 15:04 ` Erwan Velu
2019-11-27 15:07 ` [PATCH 1/2] firmware/dmi: Report DMI Bios release Erwan Velu
2019-11-27 15:07 ` Erwan Velu
2019-11-27 15:07 ` [PATCH 2/2] firmware/dmi: Report DMI Embedded Firmware release Erwan Velu
2019-11-27 15:07 ` Erwan Velu
2020-02-06 12:24 ` Jean Delvare
2020-02-06 12:25 ` Erwan Velu
2020-02-07 8:38 ` Erwan Velu
2020-02-06 12:16 ` [PATCH 1/2] firmware/dmi: Report DMI Bios release Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191021165321.60be88cd@endymion \
--to=jdelvare@suse.de \
--cc=2pi@mok.nu \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bbrezillon@kernel.org \
--cc=changbin.du@intel.com \
--cc=davem@davemloft.net \
--cc=e.velu@criteo.com \
--cc=erwanaliasr1@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=rpjday@crashcourse.ca \
--cc=sumit.garg@linaro.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.