On Mon, Mar 11, 2013 at 10:28:21PM +0100, Bjørn Mork wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote: > >> Userspace applications need to know the maximum supported message > >> size. > > > > Can't they get that from sysfs from the USB field that defines this? > > Not at the moment since we don't export it. But that is of course easy > to fix. > > This was how I started. The next problem was that this "message size" > property is common to all drivers using the cdc-wdm code (cdc-wdm, > cdc_mbim and qmi_wwan), and they all have different USB descriptors > defining it. So you would have 3 different fields (if you decided to add > a pseudo field for qmi_wwan, which hard codes a sane value) for the same > property. > > This made me create the first patch, which added a common sysfs propery > to the cdc-wdm device instead. The response to that was > "I would say that the most generic solution would be an ioctl()" > > > > Adding a new ioctl is usually not a good idea, who is going to change > > the userspace tools to properly call this ioctl? > > That will be Aleksander's job :) > > No, being serious I do realize the problem and I don't know if it is > such a good idea either. But I do know that we need some way for the > driver to let userspace know this value without having to guess too > much. > > Currently, when a userspace application sees a /dev/cdc-wdmX device, it > will have to > - check which USB interface it belongs to, > - parse the DMM descriptor if it is CDC WDM, > - parse the MBIM descriptor if it is CDC MBIM > - check if the driver is qmi_wwan if none of the above > - know which value qmi_wwan has hard coded > > No application does this. Hm, I hate to ask, but what does other OSes do (OS-X, Windows, etc.) about this? And what happens today that causes us to need this size? How have we lived so long without it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
