On Thu, 2019-10-24 at 19:01 +0300, Andriy Gapon wrote: > Also, if we universally implement GPIO_PIN_PRESET we still need to answer the > question. Because some consumer might still try to change an input, either by > mistake or for some reason, and we need a rule on how to handle that. Well, yeah, I guess just to zoom in on the core question of "what should happen if you try to set the state of a pin configured as input?" the answer would be "the controller should return ENODEV" and you could make a good case that it should do so regardless of the hardware's capabilities. Actually, for hardware that lets you set the output state while configured for input, where the drivers currently leverage that feature, we could both set the hardware and return ENODEV, and existing code like that in gpioiic will still work. But doing that also would require examining every existing driver and probably changing many of them. I'm not afraid of this aspect of any change we decide on... it's about 30 drivers, all of which will need minor changes. -- IanReceived on Thu Oct 24 2019 - 14:22:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC