lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 29 Jan 2017 16:16:11 +0100
From:   Sebastian Reichel <sre@...nel.org>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Quentin Schulz <quentin.schulz@...e-electrons.com>,
        knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
        robh+dt@...nel.org, mark.rutland@....com, wens@...e.org,
        linux@...linux.org.uk, lee.jones@...aro.org,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        thomas.petazzoni@...e-electrons.com, icenowy@...c.xyz,
        bonbons@...ux-vserver.org
Subject: Re: [PATCH 08/22] power: supply: add AC power supply driver for
 AXP20X and AXP22X PMICs

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ