The mcp2221 HID driver exposes a gpiochip device.
While gpioset seemed to work fine, gpioget always returned 1 on all 4
GPIOs of the component (0x01 for input in the field "direction",
according to the documentation).
This patch series addresses this issue by fixing the order of the fields
in the driver's representation of the chip answer, and adding
consistency to the way the callbacks prepare their command and the way
the hid event handler gets these fields.
The set callbacks use a similar mechanism, but work for now because
setting a direction/value only requires gpio-specific positioning in the
command preparation, and not in the raw_event handler.
The core of this issue being a discrepancy in the way the command and
the answer fetch their fields of interest, I would also like to ask if
we should uniformize a bit the way this driver handles gpio, and how.
I thought about several possible implementations for that:
Use mcp->gp_idx as the base offset of the gpio for set too, and modify
the raw_event handler to fetch all relevant data based on that; or set
the buffers in the mcp structure as unions of the various commands
handled and use gp_idx simply as the gpio index to access relevant data
directly from the structured representation everywhere; or go back to ye
old defines to ensure portability...
Louis Morhet (2):
HID: mcp2221: fix report layout for gpio get
HID: mcp2221: fix get and get_direction for gpio
drivers/hid/hid-mcp2221.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.17.1
On Tue, 04 Apr 2023 14:14:58 +0200, Louis Morhet wrote:
> The mcp2221 HID driver exposes a gpiochip device.
> While gpioset seemed to work fine, gpioget always returned 1 on all 4
> GPIOs of the component (0x01 for input in the field "direction",
> according to the documentation).
>
> This patch series addresses this issue by fixing the order of the fields
> in the driver's representation of the chip answer, and adding
> consistency to the way the callbacks prepare their command and the way
> the hid event handler gets these fields.
> The set callbacks use a similar mechanism, but work for now because
> setting a direction/value only requires gpio-specific positioning in the
> command preparation, and not in the raw_event handler.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.4/mcp2221), thanks!
[1/2] HID: mcp2221: fix report layout for gpio get
https://git.kernel.org/hid/hid/c/e36c31f8cac5
[2/2] HID: mcp2221: fix get and get_direction for gpio
https://git.kernel.org/hid/hid/c/ca6961d8a851
Cheers,
--
Benjamin Tissoires <[email protected]>
On Apr 04 2023, Louis Morhet wrote:
> The mcp2221 HID driver exposes a gpiochip device.
> While gpioset seemed to work fine, gpioget always returned 1 on all 4
> GPIOs of the component (0x01 for input in the field "direction",
> according to the documentation).
>
> This patch series addresses this issue by fixing the order of the fields
> in the driver's representation of the chip answer, and adding
> consistency to the way the callbacks prepare their command and the way
> the hid event handler gets these fields.
> The set callbacks use a similar mechanism, but work for now because
> setting a direction/value only requires gpio-specific positioning in the
> command preparation, and not in the raw_event handler.
As you should have seen in the automatic replied, I took that series in
because it seems to fix a rather worrying bug.
>
> The core of this issue being a discrepancy in the way the command and
> the answer fetch their fields of interest, I would also like to ask if
> we should uniformize a bit the way this driver handles gpio, and how.
> I thought about several possible implementations for that:
> Use mcp->gp_idx as the base offset of the gpio for set too, and modify
> the raw_event handler to fetch all relevant data based on that; or set
> the buffers in the mcp structure as unions of the various commands
> handled and use gp_idx simply as the gpio index to access relevant data
> directly from the structured representation everywhere; or go back to ye
> old defines to ensure portability...
Honestly, it's hard to make a choice here. You haven't got a replied
from the other mcp2221 folks in almost 10 days so I am not sure you'll
get feedback directly.
May I suggest that you work on any one of these idea, and then submit a
series? Generally, having the code ready makes it way easier to decide
if this is a good solution or not, while having 3 different vague
suggestions makes it hard to see the implications of them.
Also, just a side note, this driver is very limited in term of scope, as
it only touches one dedicated device. Which means that whatever solution
feels the more elegant to you has a good chance of being accepted :)
Cheers,
Benjamin
>
> Louis Morhet (2):
> HID: mcp2221: fix report layout for gpio get
> HID: mcp2221: fix get and get_direction for gpio
>
> drivers/hid/hid-mcp2221.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.17.1
>
>
>
>
>
On Thu, Apr 13, 2023 at 04:49:13PM +0200, Benjamin Tissoires wrote:
> As you should have seen in the automatic replied, I took that series in
> because it seems to fix a rather worrying bug.
Thanks!
> Also, just a side note, this driver is very limited in term of scope, as
> it only touches one dedicated device. Which means that whatever solution
> feels the more elegant to you has a good chance of being accepted :)
Well, using a struct to describe the layout of a message seems more
elegant; but if I'm not mistaken, taking offsets of fields in a packed
struct is UB... so I was surprised to even see that in Linux, that's why
I was wondering if I should pursue in that direction.
--
Louis