linux-kernel - Re: [PATCH 0/3] pinctrl: meson: g12a fixes

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]

Message-ID: <7ho97mgphw.fsf@baylibre.com>
Date:   Fri, 08 Feb 2019 09:27:07 -0800
From:   Kevin Hilman <khilman@...libre.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Jerome Brunet <jbrunet@...libre.com>
Cc:     "open list\:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list\:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "open list\:ARM\/Amlogic Meson..." 
        <linux-amlogic@...ts.infradead.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] pinctrl: meson: g12a fixes

Linus Walleij <linus.walleij@...aro.org> writes:

> On Mon, Jan 21, 2019 at 4:36 PM Jerome Brunet <jbrunet@...libre.com> wrote:
>> On Mon, 2019-01-21 at 14:53 +0100, Linus Walleij wrote:
>> > On Thu, Jan 17, 2019 at 11:23 AM Jerome Brunet <jbrunet@...libre.com> wrote:
>> >
>> > > This patchset fixes the initial pinctrl support added for th g12a SoC
>> > > family, which is mainly around the register regions claimed by the
>> > > driver.
>> > >
>> > > Linus, would it possible for you to provide a tag with these changes to
>> > > Kevin ?
>> >
>> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-meson-fixes
>> >
>> > > ATM, we can only use the devices for which the pinmux is already set by
>> > > the bootloader. Enabling the broken pinctrl driver could cause regressions
>> > > in kernelCI. Having a tag, would allow us to start using pinctrl on this
>> > > SoC in this cycle, w/o regression. It would be nice :)
>> >
>> > When you say "this cycle" do you mean I should target fixes (v5.0-rcN)
>> > or next (v5.1) with these patches?
>>
>> I was referring to the 5.1 release but it is a good question, I did not really
>> think about 5.0.
>>
>> Those changes are mainly fixes, so guess it could go in the 5.0 but support
>> for this SoC is still in its early stages, so either way is fine by me.
>>
>> Whatever is simpler for you I guess ;)
>
> I already merged it for devel and other stuff on top so it will be for v5.1
> as it looks now.

OK, assuming that tag is still valid (and immutable), that works for me.

Kevin