lkml.org 
[lkml]   [2020]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 0/3] platform/x86: dell-wmi: new keys
    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!


    --
    With Best Regards,
    Andy Shevchenko

    \
     
     \ /
      Last update: 2020-07-09 21:30    [W:3.826 / U:0.220 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site