On Sat, 11 Jan 2025 at 18:37, Bernhard Beschow <shentey@gmail.com> wrote:
>
> Input GPIO values such as a present SD card may get notified before the GPIO
> controller itself gets reset. Claring the input values thus loses data. Assuming
> that input GPIO events are only fired when the state changes, the input values
> shouldn't be reset.
>
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
> hw/gpio/imx_gpio.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/hw/gpio/imx_gpio.c b/hw/gpio/imx_gpio.c
> index 898f80f8c8..67c47a7280 100644
> --- a/hw/gpio/imx_gpio.c
> +++ b/hw/gpio/imx_gpio.c
> @@ -302,7 +302,6 @@ static void imx_gpio_reset(DeviceState *dev)
>
> s->dr = 0;
> s->gdir = 0;
> - s->psr = 0;
> s->icr = 0;
> s->imr = 0;
> s->isr = 0;
I guess so; we really don't do a good job of consistency about
how to handle GPIO lines that might be high on reset.
The other approach to this would be:
* devices on both ends implement three-phase reset
* device that has the GPIO line high on reset should ensure
it does the qemu_set_irq() for that in the reset "exit" phase
* device on the input end should:
- clear the input-data state to 0 in the "hold" phase
- ensure that its qemu_irq callback function does the
right thing if it's called during an "exit" phase
(probably needs no code changes)
That is more "what my mental model of the right thing is"
rather than something we actually do in many (any?) devices
today, though.
thanks
-- PMM