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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 31 May 2018 14:24:12 +0200
From:   Sebastian Gottschall <s.gottschall@...wrt.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Timur Tabi <timur@...eaurora.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering



Am 31.05.2018 um 14:12 schrieb Greg Kroah-Hartman:
> On Thu, May 31, 2018 at 06:55:55AM -0500, Timur Tabi wrote:
>> On 5/31/18 6:53 AM, Sebastian Gottschall wrote:
>>> i checked initially 4.9 with latest patches and 4.14 and reverted this
>>> line to get back to the old behaviour but a which view in the current
>>> 4.17 tree shows
>>> that the same patch has been included in 4.17. it was introduced in the
>>> kernel mainline on 12.feb 2018
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/qcom/pinctrl-msm.c?h=v4.17-rc7&id=a7aa75a2a7dba32594291a71c3704000a2fd7089
>> I believe that this patch should not be applied to *any* stable kernel.
>>
>> It completely breaks legacy GPIO numbering, and it does so intentionally.
>> That may be okay for future kernels, but IMHO it's wrong for older kernels.
> Why is it somehow ok for "future" kernels?  You can't break the api in
> the future for no reason.
>
> So this needs to be the same everywhere.  If it is broken in 4.17-rc, it
> needs to be reverted.
>
> thanks,
>
> greg k-h
i agree. i understand the reason why it was introduced, but the reason 
was a very special case which can be handled in a different way or 
specific for the affected architecture / device
and this patch alone cannot be introduced without further changes to 
device tree files which may assign those gpio numbers
i2c, leds etc. (a quick review of the current device tree files for qcom 
already showed me that they are likelly broken because of this change)

Sebastian

>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ