On Fri, Mar 31, 2017 at 08:22:55PM +0200, Hans de Goede wrote: > Hi, > > On 31-03-17 18:23, Wolfram Sang wrote: > > > >>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. > > Normally drivers call acpi_dev_gpio_irq_get themselves in their probe > method and the -EPROBE_DEFER handling is done in the drivers probe > itself, giving drivers various options to deal with irqs. > > The problem here is that the i2c system is somewhat special in that > it does irq mapping on behalf of the driver and does not even bother > to call the driver's probe() if the acpi_dev_gpio_irq_get() call > returns -EPROBE_DEFER. > > >Or maybe you simply want to be early and don't want to get deferred? Are > >we talking then about boot optimizations or necessities? > > The problem which I'm trying to fix is not having to write a (complex) > gpio driver for an undocumented PMIC which I (and AFAICT no-one) needs (*) > just because the i2c-core needs to be "special" and do the acpi_dev_gpio_irq_get > for me even though in this specific driver I don't need the irq at index > 0 at all. IOW the problem which I'm trying to fix is to get i2c_device_probe > to not out-smart me and never call my driver's probe method for > invalid reasons. I wonder if, instead of adding flags to I2C core (which I think behaves quite sanely), we could not have a "simple" GPIO stub driver for that PMIC that just registers gpiochip and does nothing (until somebody finds a use case and actually adds meat to it). This will stop acpi_dev_gpio_irq_get() returning -EPROBE_DEFER and all will be well in the kingdom. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
