Oliver Neukum <oliver@xxxxxxxxxx> writes: > On Saturday 09 February 2013 18:41:52 Bjørn Mork wrote: >> All this is unnecessarily complex and likely to make drivers and >> applications end up using different limits, causing errors which >> are hard to debug and replicate. >> >> Exporting the maximum message size from the driver simplifies >> the task for the userspace application, and creates a unified >> information source independent of device class. > > If you want it generic, you cannot bind it to the cdc-wdm driver. 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. > 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. And as you know, even it the protocol is "AT commands", GSM/3G/LTE modems have lots of vendor specific extensions which a management application just has to understand. But when it comes to cdc-wdm/qmi_wwan/cdc_mbim we could of course add an attribute saying which control protocol to expect. But what good is that? qmi_wwan would hardcode "QMI". cdc_mbim would hardcode "MBIM". And cdc-wdm wouldn't really know what to do... The two devices I have with WDM interfaces are both from Ericsson and both using AT commands. But AFAIK there is no way to know this. Or did you mean that userspace should just look at the class codes? That would work equally well for cdc-wdm and cdc_mbim, but for qmi_wwan I believe that it would just ignore the large collection of device specific information in the driver device id table. Still not sure where this is going.... I am open to discuss other ways to export the information currently available as driver names, but I don't think it adds any new 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
