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
>
> 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.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
