[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180310201033.GA1173@kmp-mobile.hq.kempniu.pl>
Date: Sat, 10 Mar 2018 21:10:33 +0100
From: Michał Kępień <kernel@...pniu.pl>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Darren Hart <dvhart@...radead.org>,
Jonathan Woithe <jwoithe@...t42.net>,
Andy Shevchenko <andy@...radead.org>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for
FUNC operations
> > #define OP_GET_CAPS 0x0
> > #define OP_GET_EVENTS 0x1
> > #define OP_SET 0x1
> > #define OP_GET 0x2
> > #define OP_GET_EXT 0x4
> > #define OP_SET_EXT 0x5
>
> This one looks pretty much okay (logical pairs IIUC).
Sadly, no, these are not logical pairs. But maybe this is a reasonable
compromise anyway:
- OP_GET_CAPS seems to be consistent between different functions; it
is an operation which returns a bitfield describing given model's
"capabilities" in a certain area (LEDs, buttons, etc.),
- some functions expose only OP_GET_CAPS, OP_SET, and OP_GET,
- some functions expose only OP_GET_CAPS and OP_GET_EVENTS,
- some function expose OP_GET_CAPS, OP_GET_EVENTS, OP_GET_EXT and
OP_SET_EXT (but not OP_SET or OP_GET, probably because 0x1 is
already "taken" by OP_GET_EVENTS).
So, given the above, does this layout look reasonable to you (at least
somewhat) or would you rather see these constants shuffled around in
some other way?
--
Best regards,
Michał Kępień
Powered by blists - more mailing lists