linux-kernel - Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Apr 2015 10:35:11 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	Ivan Khoronzhuk <ivan.khoronzhuk@...ballogic.com>,
	linux-kernel@...r.kernel.org, matt.fleming@...el.com,
	ard.biesheuvel@...aro.org, grant.likely@...aro.org,
	linux-api@...r.kernel.org, linux-doc@...r.kernel.org,
	mikew@...gle.com, dmidecode-devel@...gnu.org,
	leif.lindholm@...aro.org, msalter@...hat.com, roy.franz@...aro.org
Subject: Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to
 dmi_decode_table

Hi Matt,

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
> On Thu, 02 Apr, at 03:57:01PM, Ivan Khoronzhuk wrote:
> > 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@...ballogic.com>
> > ---
> >  drivers/firmware/dmi_scan.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> Looks good to me.
> 
> Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
   immediately, as it fixes a regression and will have to be backported
   to stable branches.

2* 2 older patches from Ivan which are currently in your efi-next tree
   if I'm not mistaken. Both were based on an old tree so they do not
   apply cleanly on kernel v4.0, I had to fix them up manually. I have
   no idea if git would be able to merge them properly, as the fix
   above changed the context even more.

3* The 3 new patches from Ivan which I am reviewing now, which are not
   applied in any public tree AFAIK.

I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

Thanks,
-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/