Splitting 1 USB port between 2 devices

Splitting 1 USB port between 2 devices

[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?

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.

Thanks,
Alexandru Stan (amstan)

Re: Splitting 1 USB port between 2 devices

[Peter Chen]

On 20-05-28 14:16:21, Alexandru M Stan wrote:
> 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).

In fact, it is two ports (roothubs) from software view, the possible risk for
this design is from hardware view, mainly for USB3

- You can't use external Type-A USB3 port
- USB3-only device should be few, USB3 devices need to consider back
compatible. And you can't only connect USB3 lines for standard USB3
device, it may cause that device can't work if it downgrade to USB2.

> 
> 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.

Bus reset is per roothub, this should not happen.

> 
> 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?

Maybe Alan knows it more.

> 
> 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.

I think it could work, the USB3 lines go to controller directly, and
xHCI driver talks with it and USB2 lines go 2.0 HUB's downstream port,
and EHCI driver talks with it, it will not influence each other.

-- 

Thanks,
Peter Chen

Re: Splitting 1 USB port between 2 devices

[Greg Kroah-Hartman]

On Thu, May 28, 2020 at 02:16:21PM -0700, Alexandru M Stan wrote:
> 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.

And the hub has no problem with this?  That's odd, I would think that it
would not like this type of configuration.

> 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.

What host controller are you using for this?

> 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).

Is it "legal" as far as the USB spec is concerned?  I would try to
answer that first before worrying about if Linux can handle it or not :)

> 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.

Which is why I don't think the hub would like this type of
configuration, as who controls the power connections?  What happens if
one device is suspended and the other isn't?

> 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?
> 
> 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.

I think you need to talk to some USB hardware engineers for this type of
question.

good luck!

greg k-h

RE: Splitting 1 USB port between 2 devices

[Andrew Goodbody]

> -----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)

Re: Splitting 1 USB port between 2 devices

[Julius Werner]

> > 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).
>
> Is it "legal" as far as the USB spec is concerned?  I would try to
> answer that first before worrying about if Linux can handle it or not :)

I don't think the question gets specifically addressed. It does at
least say this: 'A USB hub is the logical combination of two hubs: a
USB 2.0 hub and an Enhanced SuperSpeed hub. Each hub operates
independently on a separate data bus. Typically, the only signal
shared logic between them is to control VBUS.'

> > 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.
>
> Which is why I don't think the hub would like this type of
> configuration, as who controls the power connections?  What happens if
> one device is suspended and the other isn't?

USB 3.2 spec also says: 'If either the USB 2.0 hub or Enhanced
SuperSpeed hub controllers requires a downstream port to be powered,
power is turned on for the port.'

Note that since we're talking internal devices only here, the hub
usually doesn't actually supply VBUS to the device anyway. Port power
controls should only matter for whether the port is logically turned
on or not. Suspend signalling uses the data pins so the expectation is
that it should be possible separately for the USB 3.0 and USB 2.0 side
(after all, when you suspend a 3.0 hub, you also suspend both halves
separately -- right?).

Of course since hub manufacturers probably don't expect this use case,
every hub you'd want to do this with would always have to be carefully
tested first. I think the main question here is whether Linux
architecturally assumes that every port on a 3.0 hub *needs* to have a
corresponding 2.0 port and they can't both be used for separate
devices, or whether it's going to add assumptions like that at some
point in the future. Like Alex said, running this seems to work fine
on Linux 5.4 right now. The question is just whether we can expect it
to stay that way and can consider this an allowed use case in Linux
(as long as the hardware supports it) -- i.e. if other changes get
added later that break this in software, could we submit fixes for
this use case or would we be told that device configurations like this
just aren't allowed in the first place?