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
>>
>> 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.
Jonathan
>
> Maxime
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
