Hi, On Sat, Jan 28, 2017 at 02:30:22PM +0000, Jonathan Cameron wrote: > On 27/01/17 08:20, Maxime Ripard wrote: > > On Thu, Jan 26, 2017 at 02:32:21PM +0100, Quentin Schulz wrote: > >> I've come with this solution: > >> > >> ------------------------------------------------------------------------ > >> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c > >> index 012c064..117eacb 100644 > >> --- a/drivers/mfd/axp20x.c > >> +++ b/drivers/mfd/axp20x.c > >> @@ -882,7 +882,7 @@ EXPORT_SYMBOL(axp20x_match_device); > >> > >> int axp20x_device_probe(struct axp20x_dev *axp20x) > >> { > >> - int ret; > >> + int ret, irq_base; > >> > >> ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq, > >> IRQF_ONESHOT | IRQF_SHARED, -1, > >> @@ -893,8 +893,9 @@ int axp20x_device_probe(struct axp20x_dev *axp20x) > >> return ret; > >> } > >> > >> + irq_base = regmap_irq_chip_get_base(axp20x->regmap_irqc); > >> ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells, > >> - axp20x->nr_cells, NULL, 0, NULL); > >> + axp20x->nr_cells, NULL, irq_base, NULL); > >> > >> if (ret) { > >> dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret); > >> ------------------------------------------------------------------------ > >> > >> However, this implies that all cells added by the mfd driver which are > >> requesting irqs will need to be changed in the same commit to remove the > >> regmap_irq_get_virq calls. If we don't modify the drivers, they will > >> purely fail to request the irqs. > >> > >> The impacted drivers are the following: > >> > >> - drivers/extcon/extcon-axp288.c > >> - drivers/input/misc/axp20x-pek.c > >> - drivers/power/supply/axp20x_usb_power.c > >> - drivers/power/supply/axp288_charger.c > >> - drivers/power/supply/axp288_fuel_gauge.c So mostly power-supply, which is affected by this series anyways. Only input & extcon are added. > >> Is it really worth to do such a cleanup? > > > > Yes. The current behaviour goes against what everyone is expecting > > from the API. > > > >> I'm assuming that impacting four different subsystems at the same > >> time might require a bit of time to make the patch into the > >> kernel. I don't see also another way than doing one single patch for > >> all changes since the changes in the mfd driver will break all > >> aforementioned drivers. > > > > However, I think that can be fixed in a later, independant serie. This > > serie is quite big already and this has been long overdue, so I'd > > really like not to delay it once again because of a dependency on a > > cross-tree cleanup. > > It's not that cross tree really. Lining up this level of change to > go through an immutable branch pulled into each of the relevant trees > isn't too hard to arrange. I'm fine with doing this as a separate series, if it follows directly behind this one. Mainlined drivers tend to be used as template for new ones and this invalid IRQ resources are a bad example. -- Sebastian