linux-kernel - Re: [PATCH v5] usb: exynos: add workaround for the USB device bindings conflict

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: <Pine.LNX.4.44L0.1905201017340.1498-100000@iolanthe.rowland.org>
Date:   Mon, 20 May 2019 10:18:42 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
cc:     linux-usb@...r.kernel.org, <linux-samsung-soc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Markus Reichl <m.reichl@...etechno.de>,
        Måns Rullgård <mans@...sr.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Peter Chen <peter.chen@....com>
Subject: Re: [PATCH v5] usb: exynos: add workaround for the USB device bindings
 conflict

On Mon, 20 May 2019, Marek Szyprowski wrote:

> Commit 69bec7259853 ("USB: core: let USB device know device node") added
> support for attaching devicetree node for USB devices. Those nodes are
> children of their USB host controller. However Exynos EHCI and OHCI
> driver bindings already define child-nodes for each physical root hub
> port and assigns respective PHY controller and parameters to them. Those
> bindings predates support for USB device tree nodes.
> 
> To mitigate the side-effects of the conflict between those bindings,
> lets reset Exynos host controller of_node pointer before registering it
> to USB subsystem. This fixes the issue raised by the commit 01fdf179f4b0
> ("usb: core: skip interfaces disabled in devicetree"), which incorrectly
> disabled some devices on Exynos based boards.
> 
> Reported-by: Markus Reichl <m.reichl@...etechno.de>
> Suggested-by: Måns Rullgård <mans@...sr.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
> ---
> v5:
> - fixed error path handling as pointed by Alan

Acked-by: Alan Stern <stern@...land.harvard.edu>

This is assuming the whole approach makes sense in the first place --
I'll defer to other people's judgement on that.

Alan Stern