Oliver Neukum <oliver@xxxxxxxxxx> writes: > On Saturday 09 February 2013 20:16:20 Bjørn Mork wrote: >> Oliver Neukum <oliver@xxxxxxxxxx> writes: >> > On Saturday 09 February 2013 18:41:52 Bjørn Mork wrote: > >> Well, OK..., "generic" then. In the sense that the attribute stays the >> same regardless of whether the value is hardcoded in the driver (QMI), >> or parsed from wMaxCommand (CDC WDM) or wMaxControlMessage (CDC MBIM) >> >> Not sure I understand what you want here... I am trying to avoid having >> three different attributes for the three drivers currently needing this >> number. > > I would say that the most generic solution would be an ioctl() Ugh. Difficult to use from a shell script and not easy to use in debugging instructions. And why is that more generic than a sysfs attribute? I really thought the ioctl() way was deprecated and sysfs was the way forward. Isn't it? Or is that only if you don't already have a character device? >> > Really, ideally user space would not know what driver is handling >> > the control channel. >> >> Well, as it is now user space has a long tradition for looking at driver >> names. ModemManager has done that for quite while when it comes to >> serial drivers, because the driver name is one of the few information >> sources available telling it something about the expected protocols. > > But that has caused the problems. If you get cdc-acm, you know nothing. Yes, the usefulness depends on the driver. Some drivers tell you something, others do not. If we want to avoid having userspace looking at the driver of /dev/cdc-wdmX devices, then we need to add some other way to get the protocol information. Bjørn -- 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
