Re: [RFC PATCH 1/4] i2c: allow drivers to announce that they are IRQ safe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-09-04 16:25, Wolfram Sang wrote:
>> There is still the "if (in_atomic() || irqs_disabled())" thing in
>> i2c_transfer(), something we did not replicate in the recent
>> rework of i2c_smbus_xfer()
>>
>> Do we not need to do that dance in i2c_smbus_xfer() too and as apart
>> of that add ->smbus_xfer_irqless?
> 
> I'd be pragmtic here and only add it when it is needed. Nobody wanted it
> so far. It would throw lockdep warnings and irq related OOPSes if
> somebody uses SMBus for this. So, I'd expect we would know of a user.
> 
>> My guess was that many things that needs to be done "late" are
>> performed as one of the i2c_smbus_read/write... calls, but what do I
>> know? Or maybe I'm just too far ahead?
> 
> They are probably SMBus calls but my bet is that they will get emulated
> to I2C transfers. SMBus controllers are more common on PC hardware and
> above I'd say, and those seem to have so far their custom firmware
> methods to shut down.

Right, but keep in mind that (normal) emulation will still go through
the unconditional locking in i2c_smbus_xfer, so that will also be a
source of problems/oopses/splats.

> With all that being said, if there is someone who needs it, we can add
> it later.

Right. I didn't mean to say that there was anything wrong per se, just
that irqless support from the I2C core was a bit incomplete.

Cheers,
Peter



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux