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]

Date:   Fri, 8 Jun 2018 10:50:04 +0200
From:   Marek Vasut <marek.vasut@...il.com>
To:     Lee Jones <lee.jones@...aro.org>
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 06/08/2018 08:37 AM, Lee Jones wrote:
> 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.

Fine

-- 
Best regards,
Marek Vasut