linux-kernel - Re: [PATCH] usb: chipidea: Fix ULPI on imx51

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:   Wed, 30 May 2018 15:10:30 -0300
From:   Fabio Estevam <festevam@...il.com>
To:     Andrey Smirnov <andrew.smirnov@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Peter Chen <peter.chen@....com>,
        USB list <linux-usb@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Fabio Estevam <fabio.estevam@....com>,
        Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Re: [PATCH] usb: chipidea: Fix ULPI on imx51

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@...il.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@....com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@...entembedded.com>
> Cc: Fabio Estevam <fabio.estevam@....com>
> Cc: Lucas Stach <l.stach@...gutronix.de>
> Cc: Chris Healy <cphealy@...il.com>
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-usb@...r.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@...il.com>

Reviewed-by: Fabio Estevam <fabio.estevam@....com>