Re: [PATCH v2 2/2] gpio: add gpio-line-mux driver
From: Jonas Jelonek
Date: Mon Oct 27 2025 - 04:26:51 EST
Hi Peter,
On 27.10.25 08:51, Peter Rosin wrote:
>> +static int gpio_lmux_gpio_get(struct gpio_chip *gc, unsigned int offset)
>> +{
>> + struct gpio_lmux *glm = (struct gpio_lmux *)gpiochip_get_data(gc);
>> + int ret;
>> +
>> + if (offset > gc->ngpio)
>> + return -EINVAL;
>> +
>> + guard(gpio_lmux)(glm);
>> +
>> + ret = mux_control_select(glm->mux, glm->gpio_mux_states[offset]);
> Consider using mux_control_select_delay() here, with some suitable
> delay, to allow the mux to settle before reading the gpio line.
Thanks, will fix this.
> This .set implementation is completely broken. It you want to
> set a gpio to outout high/low, you presumably want the gpio to
> stay that way for at least some period of time, while whatever
> else happens that relies on the gpio to be in that state. But in
> this case only the mux select/deselect is protecting that gpio
> state, which is bound to be inadequate for anything real.
>
> Sure, you can probably build something trivial and see that the
> gpio can be manipulated, but the second something else touches
> the mux, the intended state of an output gpio line is
> (potentially) clobbered.
>
> I notice that in your target application, the sfp driver, all
> uses of gpios via the mux are inputs. Input is a much easier
> problem. At least as long as you do not require IRQ, if you
> need IRQs you face similar problems where the mux needs to be
> locked in its position for whatever period of time you can
> expect IRQs.
Yes, that why I left IRQs out here, but somehow I didn't properly
transfer that I have similar issues with output functionality.
>
> TL;DR, this .set implementation needs to be removed, there is
> simply no reasonable way to implement a muxed gpio .set in a
> pure software driver. You need some hardware to preserve the
> state if/when the mux is manipulated.
I see, thanks for pointing it out! I'll drop this in the next iteration
then and make this driver input-only.
> Cheers,
> Peter
>
Best,
Jonas