linux-kernel - Re: [PATCH v5 01/14] mfd: da9063: Replace regmap_add_irq

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180608063716.GA5278@dell>
Date:   Fri, 8 Jun 2018 07:37:16 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Marek Vasut <marek.vasut@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Marek Vasut <marek.vasut+renesas@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Mark Brown <broonie@...nel.org>,
        Steve Twiss <stwiss.opensource@...semi.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH v5 01/14] mfd: da9063: Replace regmap_add_irq_chip with
 devm counterpart

On Thu, 07 Jun 2018, Marek Vasut wrote:

> On 06/07/2018 02:41 PM, Lee Jones wrote:
> > On Thu, 07 Jun 2018, Marek Vasut wrote:
> > 
> >> On 06/06/2018 11:59 AM, Marek Vasut wrote:
> >>> Use devm_regmap_add_irq_chip() instead of plain regmap_add_irq_chip(),
> >>> which removes the need for da9063_irq_exit() altogether and also
> >>> fixes a bug in da9063_device_init() where the da9063_irq_exit() was
> >>> not called in a failpath.
> >>>
> >>> Signed-off-by: Marek Vasut <marek.vasut+renesas@...il.com>
> >>> Cc: Geert Uytterhoeven <geert+renesas@...der.be>
> >>> Cc: Lee Jones <lee.jones@...aro.org>
> >>> Cc: Mark Brown <broonie@...nel.org>
> >>> Cc: Steve Twiss <stwiss.opensource@...semi.com>
> >>> Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>
> >>> Cc: linux-renesas-soc@...r.kernel.org
> >>
> >> So it's just this one patch that's missing AB/RB and the series should
> >> be good?
> > 
> > Looks fine. Although we'll let it sit for a while in case anyone else
> > has any thoughts.
> 
> Fine by me.
> 
> > The merge window is currently open, so there is no rush to apply.
> 
> This is still 4.18 material ? Hum, OK.

You mean this could be added to v4.18?  If so, not a chance.  I
normally cut off accepting trivial patches at around -rc6(ish).  Large
sets like this require a longer soak in -next for all of the build
bots and testers to have their wicked way with them and for potential
merge conflicts to show.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog