[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180310135113.61683f08@endymion>
Date: Sat, 10 Mar 2018 13:51:13 +0100
From: Jean Delvare <jdelvare@...e.de>
To: Alex Hung <alex.hung@...onical.com>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to
dmi_matches
On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote:
> On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare <jdelvare@...e.de> wrote:
> > However it doesn't make sense to commit this change unless there will
> > be at least one user of it. What is the status of the piece of code
> > which was supposed to use this new feature?
>
> The original use of DMI on _OSI is no needed anymore - the OEM _OSI
> string will always enabled; however, this patch is still needed
> because DMI_OEM_STRING are more suitable for many DMI quirks,
> especially for Dell systems, and many, if not all, DMI quirks for Dell
> systems with DMI_PRODUCT_NAME can be (and should be) replaced by
> DMI_OEM_STRING because 1) OEM string contains system id, 2) multiple
> product names can be used for the same system id and 3) the number DMI
> quirks can be reduced.
>
> For example, the DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 9020M") in
> commit 1f59ab2783aed04f131 can be replaced by
> DMI_MATCH_EXACT(DMI_OEM_STRING, "1[0669]")
>
> I will start sending DMI quirks with DMI_OEM_STRING myself and perhaps
> sending a clean up patch to replace DMI_PRODUCT_NAME by DMI_OEM_STRING
> for the Dell systems I have access to. With this patch in place first,
> I am able to convince others to use DMI_OEM_STRING because there will
> fewer risks to spend time in vain.
Fair enough. I've fixed the blank line issue and queued your patch for
kernel v4.17, thanks for your contribution.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists