Re: [PATCH 08/22] power: supply: add AC power supply driver for AXP20X and AXP22X PMICs

From: Sebastian Reichel
Date: Sun Jan 29 2017 - 10:22:12 EST


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

Attachment: signature.asc
Description: PGP signature