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

From: Darren Hart
Date: Fri Apr 15 2016 - 00:43:07 EST


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