Re: [RFC PATCH] i2c: designware: add atomic transfer support for IRQ-off contexts

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-08-08 23:46:53 [+0300], Andy Shevchenko wrote:
> > +	/*
> > +	 * Fall back to the atomic path when IRQs are disabled, e.g. during
> > +	 * noirq system resume where an I2C client (GPIO expander, PMIC)
> > +	 * must be accessed before IRQs are re-enabled.  The i2c core's
> > +	 * i2c_in_atomic_xfer_mode() gate does not cover resume_noirq
> > +	 * (system_state is already SYSTEM_RUNNING there), so the driver has
> > +	 * to route the transfer itself.
> > +	 */
> > +	if (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? !preemptible() : irqs_disabled())
> 
> I don't like this. Do we have something better for this?
> Perhaps @bigeasy knows?

This looks hackish indeed. Couldn't this take an argument from the
caller to learn if it is called from the atomic path or the regular?
And could this be tested on PREEMPT_RT to figure out if it works as
intended? I do remember that some driver creates a warning on PREEMPT_RT
due to its atomic call path which is tested from probe. I don't remember
anyone tested it on RT other than just shutting down the warning,
claiming it is okay…

> > +		return i2c_dw_xfer_atomic(adap, msgs, num);
> 

Sebastian