All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Goodbody <andrew.goodbody@cambrionix.com>
To: Alexandru M Stan <amstan@chromium.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Julius Werner <jwerner@chromium.org>,
	Evan Green <evgreen@chromium.org>
Subject: RE: Splitting 1 USB port between 2 devices
Date: Fri, 29 May 2020 08:46:31 +0000	[thread overview]
Message-ID: <CWXP265MB240835509525CEB493DAE648858F0@CWXP265MB2408.GBRP265.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAHNYxRzH3F7r4A3hOJYWw8fwoSLBESyyN7XQ4HYfw1Y3qoNbJg@mail.gmail.com>

> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org <linux-usb-
> owner@vger.kernel.org> On Behalf Of Alexandru M Stan
> Hello,
> 
> I'm currently helping to design the hardware for yet another chromebook.
> 
> The particular SOC (and most other alternatives BTH) we're using has a
> limited amount of USB controllers available, usually just 1. Being a
> chromebook we have quite a few needs for USB though: 2 type C ports,
> pogo pins for a connected keyboard, 2 cameras, a type A port. We're
> probably going to have an internal hub no matter what, but it looks like even
> a 4 port hub might not be enough, going to yet a bigger hub (which might not
> be as power efficient) is not ideal, chaining hubs that are builtin is also meh.
> 
> I noticed that some of our cameras use the USB3.0 lines only. Other cameras,
> since they're lower resolution ones use only USB2.0. I wondered what would
> happen if the 2 types of cameras were to share a port, since none of the data
> lines are common between them.
> 
> I've built a little contraption to test this. It seems to work as intended. Both
> usb cameras seem to enumerate, I can even stream from both at the same
> time with no problem. A macbook seems to also kind of work (I can't stream
> from both for some reason, but i can open either I want). I can upload
> detailed lsusb outputs if needed.
> 
> My question here is: is this legal as far as Linux is concerned? Can 2 devices
> be enumerated under one physical port (even though we're talking about
> separate usb2.0 and 3.0 bus topologies).
> 
> It seems to work so far with our linux 5.4 chrome os fork (which as far as I
> know is identical to 5.4 LTS for matters concerning usb). But the question is
> would this keep working?
> 
> Is there any weird port reset interaction that might be annoying here?
> I wouldn't want a reset on the usb 2.0 device to affect the 3.0 device.
> 
> Is there any other higher level port management going on in linux, where
> there might be plans to keep track of things, but it's not piped enough to see
> it affect (negatively) this use case.
> 
> If this is ok, was something like this ever done before?

I cannot speak for other USB hubs but the USB7206 that I am working with at the moment has an option to split ports this way for non-removable device usage. So I would say that you need a hub that specifically has a configuration option to make this work correctly. Just trying to do it without that support is almost bound to lead to weird problems such as you see with only being able to stream from one device.

> Bonus, maybe unrelated, question: I've wondered in the past if it's legal to
> route 2.0 and 3.0 lines through different paths.
> 
> For example, imagine I had one of each:
>  * 2+3.0 controller
>  * 2+3.0 device (eg a 3.0 type A port)
>  * 2.0 device (older usb device)
> 
> Would it be legal to use only a 2.0 hub, with the 3.0 data lines for the 3.0
> device bypassing the hub. This would be cheaper than having a fully fledged
> 2+3.0 hub with the second port's 3.0 data lines wasted.

In my work I need to be able to map the physical hardware ports of a removable device onto the USB tree. Having the USB3 tree and the USB2 tree differ like this, on an external port, would give me a really bad day. So bad that I would be tempted to find the designer, in person, to teach them the error of their ways. 😉 Please bury this idea where it will never see the light of day again.

> Thanks,
> Alexandru Stan (amstan)

      parent reply	other threads:[~2020-05-29  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 21:16 Splitting 1 USB port between 2 devices Alexandru M Stan
2020-05-29  8:03 ` Peter Chen
2020-05-29  8:12 ` Greg Kroah-Hartman
2020-05-29 20:44   ` Julius Werner
2020-05-29  8:46 ` Andrew Goodbody [this message]

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=CWXP265MB240835509525CEB493DAE648858F0@CWXP265MB2408.GBRP265.PROD.OUTLOOK.COM \
    --to=andrew.goodbody@cambrionix.com \
    --cc=amstan@chromium.org \
    --cc=balbi@kernel.org \
    --cc=dianders@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.