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