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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161205090530.oleu2n3a7g4qtgta@lukather>
Date:   Mon, 5 Dec 2016 10:05:30 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Andre Przywara <andre.przywara@....com>
Cc:     Icenowy Zheng <icenowy@...c.xyz>,
        Hans de Goede <hdegoede@...hat.com>,
        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

On Fri, Dec 02, 2016 at 04:10:46PM +0000, Andre Przywara wrote:
> 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.

I disagree with this. We already have different ways of changing the
DT at runtime, and even if we didn't I'd still disagree. Once you add
that, there's simply no going back. Saying "let's enable it and we'll
figure it out later" doesn't work, and is essentially a "enable it".

So what you're suggesting is to have those regulators enabled forever,
which might be the case on that board anyway, but definitely shouldn't
be policy.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)