Re: [PATCH] fujitsu-laptop: Support radio LED

[Darren Hart]

On Tue, Apr 12, 2016 at 10:06:34PM +0930, Jonathan Woithe wrote:
> Hi Darren
> 
> On Sun, Apr 10, 2016 at 08:22:58PM +0930, Jonathan Woithe wrote:
> > On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote:
> > > Jonathan, Micha??,
> > > 
> > > Where are we with this? The above reads as "Doesn't appear to break existing
> > > systems on hand". Jonathan, are you happy with this patch?
> > 
> > Sorry, I got caught up over the last couple of weeks with other tasks and
> > have not yet managed to confirm the lack of regressions on the S7020.  It
> > was on my list for this coming week though.  My comments quoted above were
> > theoretical rather than based on an actual test.  The patch appears fairly
> > innoculous given that BTNI bit 24 is not set on the S7020 but for
> > completeness I would prefer to give it a run on the S7020 before we merge
> > the patch.  I will make an effort to fit this in over the next couple of
> > days.
> 
> I have now tested the patch on the S7020 and unsurprisingly I have not
> observed any regressions.  I'm therefore happy to take the patch more or
> less as is.  However, I would like to see a brief comment in
> acpi_fujitsu_hotkey_add() about the use of bit 24 in BTNI to determine
> whether the LED handler should be registered since the reasoning is not
> obvious and is not evident from the code.  A copy of the original patch with
> such a comment inserted (no code changes) is below.
> 
> Signed-off-by: MichaÅ? KÄ?pieÅ? <kernel@xxxxxxxxxx>

Jonathan, please check your character set, a few mangled characters here which I
have to fix up to use. UTF-8 seems to work reliably.

Your headers currently include:
Content-Type: text/plain; charset=iso-8859-1

> Acked-by: Jonathan Woithe <jwoithe@xxxxxxxxxx>
> 
> MichaÅ? hasn't indicated that a revised patch is in the works so I'm fine if
> you proceed with the one below.  I've selected the relevant parts of his
> preamble for inclusion in the commit message, but feel free to edit further
> to your taste.
> 

Yeah, tough call, some guess work involved here, and where we are uncertain, we
should document it. I don't think we need to include bits about uncertain future
plans or speculation on how things might be done. Keep it to what this patch
does and any qualifiers a developer should be aware of.

I've made a couple cosmetic changes and queued to for-next. Please review and
let me know if you have any concerns.

-- 
Darren Hart
Intel Open Source Technology Center