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  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]
Date:   Fri, 17 May 2019 13:18:59 +0200
From:   Marek Szyprowski <>
To:     Måns Rullgård <>
Cc:     Peter Chen <>,
        "" <>,
        "" <>,
        Greg Kroah-Hartman <>,
        Bartlomiej Zolnierkiewicz <>,
        Markus Reichl <>,
        Krzysztof Kozlowski <>
Subject: Re: [PATCH v3] usb: core: verify devicetree nodes for USB devices

Hi Måns

On 2019-05-13 12:03, Måns Rullgård wrote:
> Marek Szyprowski <> writes:
>> Hi Peter,
>> On 2019-05-10 05:10, Peter Chen wrote:
>>>> Marek Szyprowski <> writes:
>>>>> Commit 69bec7259853 ("USB: core: let USB device know device node")
>>>>> added support for attaching devicetree node for USB devices. The
>>>>> mentioned commit however identifies the given USB device node only by the 'reg'
>>>>> property in the host controller children nodes. The USB device node
>>>>> however also has to have a 'compatible' property as described in
>>>>> Documentation/devicetree/bindings/usb/usb-device.txt. Lack for the
>>>>> 'compatible' property check might result in assigning a devicetree
>>>>> node, which is not intended to be the proper node for the given USB device.
>>>>> This is important especially when USB host controller has child-nodes
>>>>> for other purposes. For example, Exynos EHCI and OHCI drivers already
>>>>> define child-nodes for each physical root hub port and assigns
>>>>> respective PHY controller and parameters for them. Those binding
>>>>> predates support for USB devicetree nodes.
>>>>> Checking for the proper compatibility string allows to mitigate the
>>>>> conflict between USB device devicetree nodes and the bindings for USB
>>>>> controllers with child nodes. It also fixes the side-effect of the
>>>>> other commits, like 01fdf179f4b0 ("usb: core: skip interfaces disabled
>>>>> in devicetree"), which incorrectly disables some devices on Exynos
>>>>> based boards.
>>> Hi Marek,
>>> The purpose of your patch is do not set of_node for device under USB
>>> controller, right?
>> Right.
>>> I do not understand how 01fdf179f4b0 affect your boards, some nodes
>>> under the USB controller with status is not "okay", but still want to
>>> be enumerated?
>> Please look at the ehci node in arch/arm/boot/dts/exynos4.dtsi and then
>> at the changes to that node in arch/arm/boot/dts/exynos4412-odroidx.dts.
>> Exynos EHCI controller has 3 subnodes, which matches to the physical
>> ports of it and allows the driver to enable given PHY ports depending on
>> which physical port is used on the particular board. All ports cannot
>> not be enabled by default, because PHY controller has limited resources
>> and shares them between USB host and USB device ports.
> It seems like what's happening is that the Exynos port/phy nodes are
> mistaken for standard USB device nodes attached to the root hub.  The
> problem is that hub port numbering starts at 1 while the Exynos nodes
> start from 0.  This causes attached devices to be associated with the
> wrong DT node.
> Ignoring backwards compatibility, I can see a few ways of fixing this:
> - Add another child node, along side the port@N nodes, of the host
>    controller to represent the root hub.  Nodes for attached devices
>    would then be descendants of this new node.
> - Change the Exynos HCD binding to use a more standard "phys" property
>    and get rid of the child nodes for this purpose.
> - Move the port@N nodes below a new dedicated child node of the HCD.
> The first is probably the easiest to implement since it doesn't require
> any nasty hacks to avoid breaking existing device trees.

I've posted a patch, which disables creating USB device nodes for Exynos 
HCD devices (by zeroing their of_node pointer). Then I will try to apply 
the second approach from the above list, but merging it to mainline will 
require a few more steps and some time.

Best regards
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists