[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160222090314.GB4606@pali>
Date: Mon, 22 Feb 2016 10:03:14 +0100
From: Pali Rohár <pali.rohar@...il.com>
To: Michał Kępień <kernel@...pniu.pl>
Cc: Darren Hart <dvhart@...radead.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
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 Monday 22 February 2016 09:56:50 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.
Maybe you can add documentation which we got from Dell on some ML about
this SMI call. Similarly what I added in dell-laptop.c...
> 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?
IIRC recent versions of gcc ignores "inline" keyword and inline
functions as needed when doing optimizations.
If there is some functions which must be inlined you need to to use gcc
attrbiute always_inline.
But if there is policy? I do not know, maybe somebody else should
comment it.
> > 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.
--
Pali Rohár
pali.rohar@...il.com
Powered by blists - more mailing lists