That is useful to know about lsus -v. We are measuring down to 10s of millilowatts.
On Tue, Jan 23, 2024, 5:25 PM Ben Koenig <[email protected]> wrote: > The USB descriptors reported by lsusb -v will also report the MaxPower > value of a given device. > > e.g. my Logitech keyboard is currently reporting a MaxPower usage of 98mA > while my Roccat mouse is reporting 500mA > > # lsusb -vd 046d:c53d |grep MaxPower > MaxPower 98mA > # lsusb -vd 1e7d:2dcd |grep MaxPower > MaxPower 500mA > > > This might be useful if you need to identify at what point USB power draw > becomes a problem. > -Ben > > > On Tuesday, January 23rd, 2024 at 10:10 AM, Tomas Kuchta < > [email protected]> wrote: > > > This article may tell you more about what you need > > > > https://www.baeldung.com/linux/control-usb-power-supply > > > > -T > > > > On Tue, Jan 23, 2024, 12:35 Tomas Kuchta [email protected] > > > > wrote: > > > > > echo 1 > /sys/bus/usb/drivers/usb/bind > > > > > > Will bind it again. The side effect of unbind+bind is usb bus/device > > > reset, depending on whether you are addressing bus or device > > > > > > The number(s) being echoed means: > > > usbBusNo usbPort usbDevice > > > Check the bus/device format in /sys or dmsg or .... > > > > > > There is old article from GKH about how this worked in 2.6 kernels ages > > > ago. It has changed somewhat and improved - see usb kernel sub-system > > > documentation or google for more details. > > > > > > https://lwn.net/Articles/143397/ > > > > > > I am typing this on my cell, using google and memory - I was not able > to > > > verify current format on my system at home and I use remote multi-user > > > centOS at work (cannot mess with that) > > > > > > Good luck, -T > > > > > > On Tue, Jan 23, 2024, 11:24 Vince Winter [email protected] > > > wrote: > > > > > > > It is also about the power draw on the processor power and the system > > > > power > > > > from having a USB controller working. Having any USB plugged adds > > > > noticeable amount of power. > > > > > > > > I am hoping that telling the kernel, as per the suggestions here, to > > > > unpower it that the controller goes back to "sleep mode". Also it > would be > > > > convenient if can I bring the device backup with out unplugging it. > > > > > > > > When I have a moment at work, I will get some empirical data if this > works > > > > or not. > > > > > > > > On Tue, Jan 23, 2024, 5:51 AM Tomas Kuchta > [email protected] > > > > wrote: > > > > > > > > > On Tue, Jan 23, 2024, 01:00 Ted Mittelstaedt > [email protected] > > > > > wrote: > > > > > > > > > > > I've messed with this before trying to troubleshoot USB cams. > > > > > > > > > > > > It's highly dependent on the USB hardware. Not all USB devices > > > > > > implement > > > > > > "low power" mode. > > > > > > > > > > > > Your best shot is to get a good USB 4 port hub - not a crappy > one - a > > > > > > good > > > > > > one and the good ones > > > > > > Implement power control and can cut power to a USB device if you > > > > > > command > > > > > > them to. > > > > > > . > > > > > > > > > > This is not about how the USB devices (mis)behave. They would not > be > > > > > trying > > > > > to control the devices, but the USB host(s) in the PC/laptop, I > presume. > > > > > > > > > > USB host can, and will cut power to the bus when directed. > > > > > > > > > > While I am as guilty as any man - the world really sucks when > people who > > > > > think they understand stuff speak with undoubted authority about > stuff. > > > > > > > > > > Hole it helps, -T >
