You're replying to my comment about an interface used to control such hubs, so it's what you are saying that's irrelevant in this context.
All hubs have means to control them via USB in-band (there are other things to control there than power too), and hubs that do support power switching can be controlled this way, so there's no need to use external interfaces like I2C unless you want to control such hub externally (not from the USB host), which is what this thread was about.
>You're replying to my comment about an interface used to control such hubs, so it's what you are saying that's irrelevant in this context.
Yes. An interface. Because not all hubs can be controlled in-band. Maybe you have a different definition of "control".
>All hubs have means to control them via USB in-band (there are other things to control there than power too), and hubs that do support power switching can be controlled this way, so there's no need to use external interfaces like I2C unless you want to control such hub externally (not from the USB host), which is what this thread was about.
This is wrong though. I can't control my hub. Doesn't matter that there are some other stuff I could theoretically control. (or the OS does without my intervention)
Yes. The Github link is about how to control a USB hub via I2C. From the description:
>Have you ever wanted to control USB devices using an Arduino, ESP32, or Raspberry Pi? with the i2C USB Hub, you can! Turn on or off ports of the USB hub using i2c, as well as control indicator lights and set current limits per-port.
So you saying, that you could do that in-band is wrong, because not all hubs can be controlled in-band.
Or the easy definition: no port control == not controllable.
Nothing's wrong there and you're just playing with semantics to not admit your misunderstanding. All hubs have an in-band control interface available that can be used by them to implement port power control, period.
> The Github link is about how to control a USB hub via I2C.
No, it points to a hardware design for a very specific hub that implemented its port power control via I2C. Usually hubs don't have any I2C interface at all as they don't need one, regardless of whether they do port control or not.
>Nothing's wrong there and you're just playing with semantics to not admit your misunderstanding. All hubs have an in-band control interface available that can be used by them to implement port power control, period.
You want to make it about semantics because you think that "control" means something different then what it means.
There are hubs that can't be controlled that way. Period.
./uhubctl
No compatible devices detected!
Run with -h to get usage info.
Feel free to tell me how I can get those uncontrollable hubs compatible.
This is completely irrelevant to what this subthread is about and you would know that if you had read it again instead of trying to insist that you're right.
What you're writing is still completely irrelevant.
Every USB hub has a control channel over USB and it's true regardless of how you may want to redefine the word "control". My post attempted to answer a question that popped into my mind when looking at this submission: "why would I want a USB hub that implements power control via I2C instead of USB?" (another answer could be "because it's easier to retrofit such functionality on top of a hub chip that doesn't do power control", although that one is only relevant for the designer and not for the user of such device).
Meanwhile, I just sent a command to a USB hub in my mobile phone in order to suspend a modem connected to it - something every USB hub is capable of doing and what can be controlled by the user (yes, it's a function of the hub, not of the device). But you do you, enjoy your world.
The modem (or any other device) has nothing to say when being suspended by the hub - it can't even tell whether it's being suspended selectively or whether it's the whole bus (or any upstream hub) that got suspended. You can suspend every USB device, you have full control over that. With some devices it won't give you any power savings, some won't resume correctly, some will instantly reset and some won't be able to ask the host to be resumed (initiate remote wakeup), but you can send any device to suspend by asking the hub to do so (and telling it to enable or disable remote wakeup capability as desired beforehand) and it will work. You can also ask the hub to disable the port's data connection (PORT_ENABLE) independently of controlling its power (PORT_POWER), and as opposed to power control it's actually mandated by the spec since USB 1.0 and supported universally.
uhubctl doesn't concern itself with all those features, but technically there's nothing preventing it from implementing them alongside power control.
I have spent more time reading USB specs and debugging USB connection troubles than I wish I had to.
All hubs have means to control them via USB in-band (there are other things to control there than power too), and hubs that do support power switching can be controlled this way, so there's no need to use external interfaces like I2C unless you want to control such hub externally (not from the USB host), which is what this thread was about.