Re: [PATCH 2/2] HID: mcp2221: configure GP pins for GPIO function

By mistake during development it may happen or a rogue application can
knowingly play with our hardware (commercial product may be
vulnerable). What are your thoughts?

-Rishi

On Mon, Aug 30, 2021 at 6:39 PM Tobias Junghans
[off-list ref] wrote:

Hi Rishi,

thank you for your questions. I agree with you that one usually would
reprogram the flash when manufacturing commercial products. However there's not
always the need to do so if things can be done in software as well. The code
will do no harm since a GPIO line initially is configured as input
(MCP2221_GP_GPIO_DIR_IN) when being requested. Like with any other GPIO
(driver), it's up to the user to take care of not configuring both ends as
outputs with conflicting pull downs/ups or logic levels. Also the driver's
default behaviour remains unchanged, i.e. it will not change the GP pin config
unless requested explicitly.

So all the proposed patch does it is to make the GPIO functions work as
expected OOTB when explicitly controlling them with the appropriate tools or
interfaces (libgpiod/sysfs).

Best regards

Tobias

quoted

Hi Tobias,

To me it sounds like we are discussing about commercial product
(predefined internal flash fw) v/s prototype (we want to play with
settings at runtime with ease).

Let us assume a GPx pin is configured as input and pulled up in
hardware board originally. A microcontroller's GPIO is configured as
output and connected to this GPx on MCP2221.
MCP2221 (GPx, input, pulled up) <----------- (output, no pull up/down)
STM32 Microcontroller

1. The STM32 Microcontroller drives this pin and set it to logic low
2. Driver using this patch configure this GPIO on mcp2221 end as
output and drives it to logic high
It is like two devices trying to drive same (physical wire) GPIO pin
at the same time. How we plan to handle this.

Will the GPx side will fuse or malfunction because of infinite current flow
?

Regards,
Rishi