From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: dts: sun9i: cubieboard4: Enable USB support
Date: Tue, 12 May 2015 16:57:17 +0200 [thread overview]
Message-ID: <20150512145717.GN10961@lukather> (raw)
In-Reply-To: <CAGb2v64eKcn6-J+Dae-YOtaZ3kdiT7=JMvnRJfBafXpEDLsYLg@mail.gmail.com>
On Mon, May 11, 2015 at 04:26:58PM +0800, Chen-Yu Tsai wrote:
> >> >> +&usbphy1 {
> >> >> + phy-supply = <®_usb1_vbus>;
> >> >> + status = "okay";
> >> >> +};
> >> >> +
> >> >> +/*
> >> >> + * Unfortunately reg_usb1_vbus also powers one of the ports from usb3's hub.
> >> >> + * One should always make sure both regulators are enabled and working for
> >> >> + * all USB ports to have power.
> >> >> + */
> >> >
> >> > Can't we just provide the two regulators, and enable both of them so
> >> > that we know that we always have the needed regulators enabled,
> >> > disregarding which USB port is used?
> >>
> >> Would setting "always-on" for both regulators work for you?
> >> Or maybe just the one that's used by both USB hosts?
> >
> > I was more thinking of giving to the phy an additional regulator, so
> > that it would enable both the regulators needed to power up all ports.
>
> That would require adding back all the regulator-related code I
> removed from the phy driver before it was merged. (sigh) It's not
> like the regulator bindings takes a list.
Yeah, but maybe we can just add an optional device-supply property or
something like that to power up the devices connected on the bus.
> I see this as more of a hardware design flaw, and we should label
> it as such.
This can be seen as one, and we can debate it for some time I guess,
but if the hardware guys were not making crazy stuff like that, we
would run out of work pretty quickly :)
What we really need to do is find a proper and reliable way to handle
this case. Whether we declare it as a flaw or not is a separate
debate.
> And it might still work for self-powered devices even if VBUS is
> off. The USB hub chip is always on.
That still leaves a significant amount of devices out and non
functional, especially very standard devices like USB keys, keyboards
or headsets that you would expect to just work.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150512/b950273a/attachment.sig>
next prev parent reply other threads:[~2015-05-12 14:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 16:43 [PATCH 0/2] ARM: sun9i: cubieboard4: Enable USB hosts and LEDs Chen-Yu Tsai
2015-05-07 16:43 ` [PATCH 1/2] ARM: dts: sun9i: cubieboard4: Enable USB support Chen-Yu Tsai
2015-05-08 7:46 ` Maxime Ripard
2015-05-08 8:01 ` Chen-Yu Tsai
2015-05-08 11:40 ` Maxime Ripard
2015-05-11 8:26 ` Chen-Yu Tsai
2015-05-12 14:57 ` Maxime Ripard [this message]
2015-05-12 15:49 ` Chen-Yu Tsai
2015-05-07 16:43 ` [PATCH 2/2] ARM: dts: sun9i: cubieboard4: Enable LEDs Chen-Yu Tsai
2015-05-08 1:10 ` [PATCH 0/2] ARM: sun9i: cubieboard4: Enable USB hosts and LEDs Tyler Baker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150512145717.GN10961@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.