Oct 31, 2023 03:10:50 Anshul Dalal <anshulusr@xxxxxxxxx>:
> Hello Thomas,
>
> Thanks for the review! The requested changes will be addressed in the
> next patch version though I had a few comments below:
>
> On 10/27/23 11:44, Thomas Weißschuh wrote:
>> Hi Anshul,
>>
>> thanks for the reworks!
>>
>> Some more comments inline.
>>
>> On 2023-10-27 10:48:11+0530, Anshul Dalal wrote:
[..]
>>> +struct seesaw_button_description {
>>> + unsigned int code;
>>> + unsigned int bit;
>>> +};
>>> +
>>> +static const struct seesaw_button_description seesaw_buttons[] = {
>>> + {
>>> + .code = BTN_EAST,
>>> + .bit = SEESAW_BUTTON_A,
>>> + },
>>> + {
>>> + .code = BTN_SOUTH,
>>> + .bit = SEESAW_BUTTON_B,
>>> + },
>>> + {
>>> + .code = BTN_NORTH,
>>> + .bit = SEESAW_BUTTON_X,
>>> + },
>>> + {
>>> + .code = BTN_WEST,
>>> + .bit = SEESAW_BUTTON_Y,
>>> + },
>>> + {
>>> + .code = BTN_START,
>>> + .bit = SEESAW_BUTTON_START,
>>> + },
>>> + {
>>> + .code = BTN_SELECT,
>>> + .bit = SEESAW_BUTTON_SELECT,
>>> + },
>>> +};
>>
>> This looks very much like a sparse keymap which can be implemented with
>> the helpers from <linux/input/sparse-keymap.h>.
>>
>
> When going through the API provided by sparse-keymap, I could only see
> the use for sparse_keymap_report_entry here. Which leads to the
> following refactored code:
>
> static const struct key_entry seesaw_buttons_new[] = {
> {KE_KEY, SEESAW_BUTTON_A, {BTN_SOUTH}},
> {KE_KEY, SEESAW_BUTTON_B, {BTN_EAST}},
No braces I think.
> ...
> };
>
> for (i = 0; i < ARRAY_SIZE(seesaw_buttons_new); i++) {
> sparse_keymap_report_entry(input, &seesaw_buttons_new[i],
> data.button_state & BIT(seesaw_buttons_new[i].code),
> false);
> }
>
> I don't think this significantly improves the code unless you had some
> other way to use the API in mind.
I thought about sparse_keymap_setup() and sparse_keymap_report_event().
It does not significantly change the code but would be a standard API.
Thomas
