Message-ID: <20211115170825.24a13cf3@Zen-II-x12.niklas.com>
Date:   Mon, 15 Nov 2021 17:08:25 -0500
From:   David Niklas <Hgntkwis@...mail.net>
To:     linux-kernel@...r.kernel.org
Cc:     stern@...land.harvard.edu, linux-usb@...r.kernel.org,
        linux-input@...r.kernel.org
Subject: Re: I need advice with UPS connection. (ping)

On Mon, 15 Nov 2021 11:09:18 -0500
stern@...land.harvard.edu wrote:
> On Sun, Nov 14, 2021 at 10:02:22PM -0500, David Niklas wrote:
> >
<snip>
> Has this device ever worked with any version of Linux?

I am unaware of this device working on any version of Linux. I assumed
when I bought it that it would a least be able to connect to the USB port
correctly. I might then have to make a contribution to add support for it
to nut or apcupsd.

<snip>
> The kernel sends a Set-Idle request to the device, telling it not to 
> send any data reports when nothing has changed.  This is done 
> automatically by the usbhid driver for every USB HID device, including 
> keyboards and mice as well as your UPS.
> 
> ffff93eaa3edad80 2136086737 S Ci:3:009:0 s 81 06 2200 0000 03e4 996 <
> ffff93eaa3edad80 2136122734 C Ci:3:009:0 0 996 = 05840904 a1010924
> a1028501 09fe7901 75089501 150026ff 00b12285 0209ff79
> 
> The kernel reads the device's HID descriptor.  (The usbmon trace shows 
> only the first 32 bytes of the 996-byte descriptor.)  Again, this is 
> normal and necessary for using any HID device.
> 
> ffff93e482efb440 2139520170 C Ii:3:001:1 0:2048 1 = 08
> ffff93e482efb440 2139520180 S Ii:3:001:1 -115:2048 4 <
> 
> At this point the USB controller tells the kernel that there has been a 
> status change on port 3 of bus 3.
> 
> ffff93eaa2ff8240 2139520188 S Ci:3:001:0 s a3 00 0000 0003 0004 4 <
> ffff93eaa2ff8240 2139520197 C Ci:3:001:0 0 4 = 00010100
> 
> The kernel reads the port's status and sees that there is a "connection 
> status change" bit set and the port is no longer connected.  In other 
> words, the UPS device has disconnected itself electronically from the 
> USB bus.
> 
> ffff93eaa2ff8240 2139520200 S Co:3:001:0 s 23 01 0010 0003 0000 0
> ffff93eaa2ff8240 2139520203 C Co:3:001:0 0 0
> 
> The kernel clears the "connection status change" flag.  Following this 
> the cycle repeats.
> 
> 
> Out of all this information, the only conclusion I can draw is that the 
> UPS is not behaving like a normal device.  One possibility is that it 
> doesn't like the Set-Idle request (although if that is the case, why 
> did it remain connected long enough to send the HID descriptor?).

Thanks for the detailed breakdown!

> You can test the theory by patching the kernel, if you want.  The code 
> to change is in the source file drivers/hid/usbhid/hid-core.c, and the 
> function in question is hid_set_idle() located around line 659 in the 
> file.  Just change the statement:
> 
> 	return usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> 		HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> (idle << 8) | report, ifnum, NULL, 0, USB_CTRL_SET_TIMEOUT);
> 
> to:
> 
> 	return 0;
> 
> to prevent the Set-Idle request from being sent.  If the device still 
> insists on disconnecting then we'll know that this wasn't the reason.

Will do tomorrow. (I'm busy ATM)

> Also, if you have another system (say, one running Windows) which the 
> UPS does work properly with, you could try collecting the equivalent of 
> a usbmon trace from that system for purposes of comparison.  (On 
> Windows, I believe you can use Wireshark to trace USB communications.)
> 
> Alan Stern
> 

I'll have to look into that.

Thanks again!
David

Powered by blists - more mailing lists