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
