Re: [PATCH v5 06/15] iio: adc: ad4134: Protect conventional device access from debug accesses

[Jonathan Cameron]

On Mon, 19 Oct 2026 18:04:28 -0300
Marcelo Schmitt <marcelo.schmitt1@xxxxxxxxx> wrote:

> On 10/17, Jonathan Cameron wrote:
> > On Fri, 16 Oct 2026 22:58:05 -0300
> > Marcelo Schmitt <marcelo.schmitt@xxxxxxxxxx> wrote:
> >   
> > > Require debug access to acquire device synchronization locks before
> > > allowing any transfer from the debug interface so to avoid disrupting
> > > operations issued from usual (non-debug) interfaces.  
> > 
> > These needs more.  What sort of disruption are we talking?
> > 
> > A deliberate write to change state that breaks normal operation
> > is a debug mess up that we don't guard against, but if a read
> > is enough to break things, or there is an inherent disruption
> > of other operations by using the bus at all then state that.  
> 
> A read is enough to break any ongoing buffered read because register reads will
> cause the bus configuration to change to a state that invalidates any sample read
> that happens afterwards. 

 Capture that in the commit message.

> 
> > 
> > What isn't regmap locking covering?    
> 
> regmap doens't cover IIO device direct/buffered modes.
> 
> > 
> > If this is all about the mux stuff and backend usage,
> > then move it to nearer that in the series and refer to that.  
> 
> We also need the mux usage to be synchronized which is why debugfs_reg_access
> now also locks on device state sync_lock.
> 
> In practice, because every device access will select then deselect the mux state,
> we are not able to have two operations going on simultaneously (not even two
> register read can run concurrently due to the needed mux state care).
> 
> On v3, there was a dedicated mutex for mux access synchronization. In an atempt
> to make things more simple, that second mutex was removed and sync_lock is now
> also utilized to prevent multiple threads from changing the mux state simultaneously. 
> It shall work properly as long as any device access first
> claims IIO direct + get sync_lock or claims IIO buffered mode.
> Is it okay to have it like that?

That seems fine.  Just add some documentation on the requirements in
appropriate places.

Jonathan