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

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

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