linux-kernel - Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board

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-next>] [day] [month] [year] [list]

Message-ID: <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
Date:   Fri, 2 Dec 2016 16:10:46 +0000
From:   Andre Przywara <andre.przywara@....com>
To:     Icenowy Zheng <icenowy@...c.xyz>,
        Hans de Goede <hdegoede@...hat.com>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Jonathan Corbet <corbet@....net>, Chen-Yu Tsai <wens@...e.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board

Hi,

On 02/12/16 14:32, Icenowy Zheng wrote:
> 
> 
> 02.12.2016, 22:30, "Hans de Goede" <hdegoede@...hat.com>:
>> Hi,
>>
>> On 02-12-16 15:22, Icenowy Zheng wrote:
>>>  01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@...e-electrons.com>:
>>>>  On Mon, Nov 28, 2016 at 12:29:07AM +0000, André Przywara wrote:
>>>>>   > Something more interesting happened.
>>>>>   >
>>>>>   > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>>>   > two USB Controllers exported at expansion bus as USB Type-A
>>>>>   > connectors.
>>>>>   >
>>>>>   > Also it exposes a analog A/V jack and a microphone.
>>>>>   >
>>>>>   > Should I enable {e,o}hci{2.3} in the device tree?
>>>>>
>>>>>   Actually we should do this regardless of this extension board. The USB
>>>>>   pins are not multiplexed and are exposed on user accessible pins (just
>>>>>   not soldered, but that's a detail), so I think they qualify for DT
>>>>>   enablement. And even if a user can't use them, it doesn't hurt to have
>>>>>   them (since they are not multiplexed).
>>>>
>>>>  My main concern about this is that we'll leave regulators enabled by
>>>>  default, for a minority of users. And that minority will prevent to do
>>>>  a proper power management when the times come since we'll have to keep
>>>>  that behaviour forever.
>>>
>>>  I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>>
>> I don't think that will be necessary I'm pretty sure these extra usb
>> ports do not have a regulator for the Vbus, they just hook directly
>> to the 5V rail, can someone with a schematic check ?
> 
> We seems to have still no schematics for the add-on board.

>From looking at the picture of that expansion board on the Aliexpress
page and chasing the tracks, there is clearly no voltage regulator on
there, it's just passive components. The 5V pin from the headers is
routed forth and back between the two layers via some vias directly to
the 5V pins of the USB sockets.

> But something is sure is that there's no any regulator-related pins
> on the add-on pinout. There's only USB DM and DP pins.
> 
> So the Vbus must be directly connected to +5V.

So yes, it is.

But I think the question is moot anyways, since we don't provide DT
support for that add-on board at that point anyways.
One could imagine another board, though, which has regulators switched
by GPIOs, but that would be their problem and they would have regulators
specified in their specific DT snippet, then.

So to summarize:
- For that specific Orange Pi Zero board which we discuss the DT for
there is no regulator support for the additional USB ports. Thus nothing
we could turn off to save power.
- A user could just take these USB brackets with pin headers that are so
common in PCs to connect additional USB ports to the back of the box.
One just needs to re-sort the pins, which is a matter of a minute.
- As long as we don't provide any easy way of handling DT changes, we
should enable the USB ports for the sake of the users of either those
brackets or the expansion board. Any more sophisticated USB expansion
board with regulators would need to amend the DT anyway.

Does that make sense?

Cheers,
Andre.