Re: [PATCH v3 5/5] drm/xe/i2c: Report i2c irq handler issue

[Raag Jadav <raag.jadav@intel.com>]

On Mon, Jun 08, 2026 at 08:04:29PM +0530, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Wajdeczko, Michal <michal.wajdeczko@intel.com> 
> > On 6/5/2026 11:05 PM, Jonathan Cavitt wrote:
> > > Error logging is expected but not included in xe_i2c_irq_handler() for
> > > generic_handle_irq_safe(), so add error logging there.
> > > 
> > > This issue was caught by static analysis.
> > 
> > hmm, what exactly was this tool complaining about?
> 
> It is complaining that xe_i2c_irq_handler() is the only place where
> the return value for generic_handle_irq_safe() is not checked.
> 
> > 
> > almost no other callers of the generic_handle_irq_safe() are printing any errors
> > (which are more about programming mistakes than runtime failures)
> > 
> > I'm asking, as if we believe that such errors are legit then maybe we shouldn't
> > 
> > 	"Deassert after I2C adapter clears the interrupt"
> 
> Is this not also the case for every other caller of
> generic_handle_irq_safe()?  If generic_handle_irq_safe() fails,
> and it fails for a legitimate reason, we really should be doing
> something about that other than just logging the error and
> moving on.  Since we don't, based on historical usage, I don't
> think whatever error generic_handle_irq_safe() can throw is
> a legitimate issue that requires intervention.
> 
> But you don't have to believe just me about it.  Raag Jadav
> also approves of this implementation where we don't do
> anything about the error other than just log it, and he's the
> one that wrote xe_i2c_irq_handler().

Possible generic_handle_irq_safe() error cases are

1. Missing irq descriptor
2. Called in process ctx when set to enforced irq ctx

Both of which are programming mistakes and unrelated to hardware.

Raag