[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdEtHfGavFBaC9Y2=bzX5pAeLqnssBE1owudRv9pKDAXw@mail.gmail.com>
Date: Thu, 9 Jul 2020 22:29:42 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Mario Limonciello <Mario.Limonciello@...l.com>
Cc: Andy Shevchenko <andy@...radead.org>,
Darren Hart <dvhart@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
Matthew Garrett <mjg59@...f.ucam.org>, y.linux@...itcher.com,
Pali Rohár <pali@...nel.org>
Subject: Re: [PATCH v4 0/3] platform/x86: dell-wmi: new keys
On Wed, Jun 10, 2020 at 10:23 PM <Mario.Limonciello@...l.com> wrote:
>
> > -----Original Message-----
> > From: Y Paritcher <y.linux@...itcher.com>
> > Sent: Wednesday, June 10, 2020 12:57 PM
> > To: Pali Rohár
> > Cc: linux-kernel@...r.kernel.org; platform-driver-x86@...r.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@...l.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!
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists