Re: [PATCH v4 0/3] platform/x86: dell-wmi: new keys

["Pali Rohár" <pali@kernel.org>]

On Monday 13 July 2020 09:29:12 Pali Rohár wrote:
> On Thursday 09 July 2020 22:29:42 Andy Shevchenko wrote:
> > On Wed, Jun 10, 2020 at 10:23 PM <Mario.Limonciello@dell.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Y Paritcher <y.linux@paritcher.com>
> > > > Sent: Wednesday, June 10, 2020 12:57 PM
> > > > To: Pali Rohár
> > > > Cc: linux-kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> > > > Matthew Garrett; Limonciello, Mario
> > > > Subject: [PATCH v4 0/3] platform/x86: dell-wmi: new keys
> > > >
> > > >
> > > > [EXTERNAL EMAIL]
> > > >
> > > > change since v3:
> > > >     No code changes.
> > > >     Update commit message to reflect info given by Mario at dell.
> > > >
> > > > Is there anything more i have to do for the patches that were reviewed
> > > > or will they be picked up by the maintainers?
> > > > Thanks
> > > >
> > > > Y Paritcher (3):
> > > >   platform/x86: dell-wmi: add new backlight events
> > > >   platform/x86: dell-wmi: add new keymap type 0x0012
> > > >   platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff
> > > >
> > > >  drivers/platform/x86/dell-wmi.c | 28 +++++++++++++++++++++++++---
> > > >  1 file changed, 25 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.27.0
> > >
> > > Andy,
> > >
> > > The whole series looks good to me now.  You can put this on the patches
> > > when they're swooped up.
> > >
> > > Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
> > >
> > > However I would like to note there was a comment that you had a direct question
> > > asked by Pali that probably got lost in the thread.  This was on patch 3/3 on v3.
> > > I think it's worth answering as it could dictate a follow up patch to change behavior.
> > >
> > > The summary of my argument which led to his is nested somewhere in the thread was that
> > > to most users this isn't useful since they can't act on it.  IE they can't use something
> > > like setkeycodes and go on their merry way.  The user who could act on it by coming
> > > to upstream and submitting questions and patches is more technical and having them
> > > use dyndbg to turn on the messages about unknown shouldn't be a big deal.
> > >
> > > > I'm not sure, but I thought that
> > > > throwing warning or info message is the correct solution. Driver cannot
> > > > handle something, so it inform about it, instead of silently dropping
> > > > event. Same behavior I'm seeing in other kernel drivers.
> > >
> > > > But looks like that you and Mario have opposite opinion, that kernel
> > > > should not log unknown events and rather should drop them.
> > >
> > > > I would like to have behavior of dell-wmi same as in other drivers for
> > > > consistency, so the best would be to ask WMI/platform maintainers. They
> > > > could have opinion how to handle these problem globally.
> > >
> > > > ...
> > >
> > > > Darren & Andy, could you please say something to this, what do you think
> > > > about silently dropping events/actions which are currently unknown for
> > > > dell-wmi driver? It is better to log them or not? Currently we are
> > > > logging them.
> > >
> > > Can you please advise which way you would rather have the subsystem go?
> > 
> > Seems Pali is okay with this version, so everything is settled I suppose.
> > I will add it to my queue, thanks!
> 
> Hello Andy! Yes, I'm fine with this patch series, but question how to
> handle these "unknown" events still remains.

Hello Andy! This question for platform-x86 maintainers is still open.
Could you look at it?