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]

Date:	Mon, 22 Feb 2016 09:56:50 +0100
From:	Michał Kępień <kernel@...pniu.pl>
To:	Darren Hart <dvhart@...radead.org>
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

> >  /*
> >   * 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?

> 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.

-- 
Best regards,
Michał Kępień