On Mon, Jun 08, 2026 at 08:04:29PM +0530, Cavitt, Jonathan wrote: > -----Original Message----- > From: Wajdeczko, Michal <[email protected]> > > 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
