> Note I said "flag in i2c_driver" the idea is that the driver can tell > the i2c_core that it is not going to use i2c_client->irq by > setting i2c_driver->no_irq and that the i2c_core then will not bother > with trying to get an irq in i2c_device_probe(), this is esp. useful > for ACPI i2c instantiated devices where we otherwise might end up > returning -EPROBE_DEFER (waiting for an irq to show up) without > needing the irq, which is esp. troublesome when there is no driver > for the irqchip the ACPI irq resource points to as then we end up > waiting indefinitely. Okay, thanks. I understand the big picture. But does it really need to be fixed in I2C core? Independent of I2C: if an irq is described in ACPI and the driver for the needed irq controller is not available, that can lead to various problems everywhere. Or maybe you simply want to be early and don't want to get deferred? Are we talking then about boot optimizations or necessities?
Attachment:
signature.asc
Description: PGP signature
