Re: [PATCH v4 10/13] iio: adc: ad4134: Support SPI 4-wire mode

["Nuno Sá" <nuno.sa@analog.com>]

On Tue, Oct 13, 2026 at 06:10:57PM -0300, Marcelo Schmitt wrote:
> On 10/06, sashiko-bot@kernel.org wrote:
> ...
> > [Severity: Medium]
> > If spi_setup() fails here, we return the error but st->spi->mode remains
> > modified. On subsequent calls, cur_mode != SPI_MODE_0 will evaluate to false
> > because the cached mode reflects the requested state.
> > 
> > Can this cause the driver to bypass spi_setup() on subsequent calls and
> > attempt to communicate with the device while the SPI hardware remains
> > incorrectly configured?
> 
> Seems to make sense. Will double check and fix if needed.
> 
> ...
> > [Severity: High]
> > Does this cause a deadlock during device probe in NO_CS mode?
> > 
> > Here the driver acquires and permanently selects the SDO multiplexer via
> > devm_mux_state_get_optional_selected(), which acquires the multiplexer's
> > non-recursive semaphore.
> > 
> > Immediately after, probe calls ad4134_min_io_mode_setup(), which writes to
> > device registers via regmap_update_bits(). This triggers the following call
> > chain:
> > 
> > ad4134_min_io_mode_setup()
> >   regmap_update_bits()
> >     ad4134_reg_write()
> >       ad4134_claim_reg_access()
> > 
> > ad4134_claim_reg_access() unconditionally calls mux_state_select(), which
> > will attempt to acquire the exact same semaphore already held by the current
> > task, causing a deadlock.
> > 
> > Furthermore, ad4134_release_reg_access() then unconditionally calls
> > mux_state_deselect(), which would prematurely release the probe-acquired
> > lock.
> 
> Seems plausible. Will double check and fix if needed.
> 
> 
> Other LLM comments don't seem to apply either because they are related to debug
> interface usage or marginal issues.

Hmm don't agree. Don't disregard debugfs claim just because it's a debug
interface. Looks like a real issue to me (very easy to trigger) that
needs fixing (same as the other patch).

- Nuno Sá