[Nut-upsdev] usbhid-ups fails with Belkin F6C120-UNV in nut-2.4.3

[Jon Burgess]

On Sun, 2010-03-21 at 11:49 +0100, Arjen de Korte wrote:
> Citeren Jon Burgess <jburgess777 at googlemail.com>:
> 
> >> Several years ago on the linux-usb list, it was often pointed out that
> >> the kernel was supposed to honor the wMaxPacketSize field, and
> >> fragment the requests accordingly. While this was suggested for
> >> performance reasons (fewer round trips between user and kernel space),
> >> it should still hold true for less frequent transfers.
> > In this case we are reading the data, I don't know if there is much the
> > kernel can do to fragment this, I don't see any concept of an offset
> > field when reading the report.
> 
> There is no need for an offset field. If you read/write the same  
> report again and the device will return/accept the next chunk of data.  
> The drawback here is that this most likely lead to a timeout after the  
> last available data has been read on the next read operation. We need  
> to deal with that.

That sounds close to a description of how the low level USB protocol
works, performing multiple IN requests until all the data has been
fetched[1]. I believe the transactions at this level are handled by the
host controller hardware and kernel driver and probably hidden from the
user space APIs. I don't see anything in the HID specification about
data for a single report needing to be split across multiple get_report
requests.

In one of my other emails I included an example of where usbhid-ups
successfully fetches the 801 byte hid descriptor in a single request
from this same device so the kernel and UPS must be able to fulfil some
longer requests successfully. 

I would guess that this UPS is not willing or able to provide more than
an 8 byte response to a Get_Report request. Looking at the datasheet for
some of the simple low speed USB microcontrollers shows that they
normally have a 8 byte transmit buffer and the firmware has to fill this
in response to an interrupt. It would not surprise me if the firmware on
the controller in this device was never coded to handle more than an 8
byte get_report request because all its reports were limited to 1, 2 or
4 byte values.

> Best regards, Arjen

	Jon


1: http://www.beyondlogic.org/usbnutshell/usb4.htm#Control