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:   Wed, 21 Nov 2018 04:36:58 +0530
From:   Sekhar Nori <nsekhar@...com>
To:     "J, KEERTHY" <j-keerthy@...com>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Kevin Hilman <khilman@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Grygorii Strashko <grygorii.strashko@...com>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        <stable@...r.kernel.org>, Lokesh Vutla <lokeshvutla@...com>
Subject: Re: [PATCH 1/3] ARM: davinci: define gpio interrupts as separate
 resources

On 20/11/18 12:08 PM, J, KEERTHY wrote:
> 
> 
> On 11/20/2018 2:22 AM, Sekhar Nori wrote:
>> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>>
>>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
>>> IRQ numbering") the davinci GPIO driver fails to probe if we boot
>>> in legacy mode from any of the board files. Since the driver now
>>> expects every interrupt to be defined as a separate resource, split
>>> the definition in devices-da8xx.c instead of having a single continuous
>>> interrupt range.
>>>
>>> Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ
>>> numbering")
>>> Cc: stable@...r.kernel.org
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>
>> There are a number of other boards that need such fixing too. And the
>> commit in question does not do a good job of explaining why it was
>> needed in the first place. The description  just repeats what can be
>> inferred by reading the patch.
> 
> Cc Lokesh
> 
> Sekhar,
> 
> DT explicitly mentions every IRQ number. The patch in discussion
> explicitly calls platform_get_irq for all the interrupts which to me is
> the right thing to do as: platform_get_irq-->
> of_irq_get-->irq_create_of_mapping--> sequence is to be done for every IRQ.
> 
> k3-am654 definitely will need explicit calls to platform_get_irq as it
> will be involving interrupt router and interrupt numbers need not be
> continuous.
> 
> So i do not think reverting the patch is the right idea.

Well, all of this description of patch motivation should have been in
the patch description to begin with.

Bartosz, can you please extend this patch to fix this problem for other
DaVinci SoCs too? I am on the road this week, but will do my best to
queue these fixes at the earliest .

Thanks,
Sekhar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ