Date: Thu, 24 Oct 2019 10:22:21 -0600 From: Ian Lepore <ian@freebsd.org> To: Andriy Gapon <avg@FreeBSD.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: gpiobus: setting output value while in input mode Message-ID: <d483faa732c2f5df80bf1f40e3c54503c362a9e8.camel@freebsd.org> In-Reply-To: <a3b07818-13c1-c55b-dbc2-239975378d31@FreeBSD.org> References: <e576cd5c-0585-fabf-67f2-1afedb4fafb8@FreeBSD.org> <c2c1de53fb9611198e1205f021b1620cd279e2dd.camel@freebsd.org> <a3b07818-13c1-c55b-dbc2-239975378d31@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d483faa732c2f5df80bf1f40e3c54503c362a9e8.camel>