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