Hi,

On 30-03-17 22:39, Wolfram Sang wrote:

Hi Hans,

quoted

Sorry for doing this in the middle of the thread, but this is the only
mail I could find in my archives (I guess I delete mail to aggressively).

I use patchwork to track patches (which is mentioned in MAINTAINERS).
And patchwork has the nice feature to download patches or series of
patches as mbox. And from there you can reply directly, or bounce to
yourself first, etc. That's what I do when I lost a mail.

Ok, I will do that the next time.

quoted

Anyways self-nack for this series, there are multiple issues with it:

1) In hindsight the irq_index is a bad idea and instead we need a noirq
flag in i2c_driver

What do you mean by that? No IRQ assigned? In Linux, 0 is no irq. I
guess you mean something else...

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.

I hope this makes things more clear, if you've another suggestion
for handling this I'm all ears.

Regards,

Hans