linux-kernel - Re: [PATCH v3 3/5] dell-wmi: enable receiving WMI events on Dell Vostro V131

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]

Message-ID: <20160222211703.GB14101@dvhart-mobl5.amr.corp.intel.com>
Date:	Mon, 22 Feb 2016 13:17:03 -0800
From:	Darren Hart <dvhart@...radead.org>
To:	Michał Kępień <kernel@...pniu.pl>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Pali Rohár <pali.rohar@...il.com>,
	Darek Stojaczyk <darek.stojaczyk@...il.com>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/5] dell-wmi: enable receiving WMI events on Dell
 Vostro V131

On Mon, Feb 22, 2016 at 09:56:50AM +0100, Michał Kępień wrote:
> > >  /*
> > >   * Certain keys are flagged as KE_IGNORE. All of these are either
> > >   * notifications (rather than requests for change) or are also sent
> > > @@ -513,6 +533,7 @@ static int __init dell_wmi_init(void)
> > >  {
> > >  	int err;
> > >  	acpi_status status;
> > > +	struct calling_interface_buffer *buffer;
> > 
> > Please place the longest line first, and move int err to the last declaration.
> > When changing declarations of local variables, please use "Reverse Christmas
> > Tree" order (longest line to shortest line) wherever possible.
> 
> Thanks, I'll keep that in mind for the future, though putting the
> WMI-enabling SMBIOS request in a separate function renders the need for
> the buffer variable in dell_wmi_init() void, so v4 won't touch this area
> any more.
> 
> > Pali's point about documenting the hardcoded values and eliminating the code
> > duplication with a function (inline) is a good one.
> 
> I plan to only put a comment next to 0x51534554 as 0x10000 is apparently
> just something pulled out of a hat (as the link provided in the commit
> message proves) and input[3] should be self-explanatory due to the name
> of the variable whose value is put into it.
> 
> By the way, is there any kernel-wide or subsystem-wide policy for
> marking a function inline?  I mean, this is hardly time-critical code,
> so is your suggestion to make it inline just a preference or am I
> unaware of some rule?

I suggested inline because the code was inline before and there would be no size
overhead to continue to make it inline. That said, the best source of guidance
on this is in CodingStyle, Chapter 15. While this function is quite small and
static to the file, it is not performance critical as you say. So, upon closer
inspection, there is no real need to be inline. And in fact, as there is no need
for it, it perhaps should not be. Thanks for raising the question.

> 
> > Otherwise, this series looks good to me. Looking forward to merging v4.
> 
> I'll try to post a v4 within the next couple of days.

Great, thank you.

-- 
Darren Hart
Intel Open Source Technology Center