On Sat, Mar 10, 2018 at 10:10 PM, Michał Kępień <kernel@xxxxxxxxxx> wrote: >> > #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). Interesting. Does it mean there is no logic between functions on the same platform and what they are expose? May be those sets might be groupped by what kind of functions expose them? > 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? If no other way is feasible right now, the above is okay to me. -- With Best Regards, Andy Shevchenko
