Re: Splitting 1 USB port between 2 devices

[Julius Werner <jwerner@chromium.org>]

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