Oliver Neukum <oliver@xxxxxxxxxx> writes:
> Am Mittwoch, 25. Januar 2012, 10:36:10 schrieb Bjørn Mork:
>> But I don't think it's a good idea to add this device to cdc-wdm
>> permanently anyway. It's useless without the network driver for
>> anything but playing with QMI commands. It's better to get Gobi
>> specific probing into qmi_wwan (or similar if making a Gobi-only
>> driver), and just use cdc-wdm as a subdriver from that.
>
> Better or necessary?
>
>> And in fact I'm also starting to wonder if it was a good idea to add the
>> Huawei modem. If the subdriver approach is accepted, then maybe it
>> would be better to use that for every such device including those with
>
> No. We leave policy to user space. If it is possible we let the user
> do as he will. Whether it makes sense doesn't interest in the kernel
> (first order approximation)
Hello,
Reasons to revisit this discussion just came up.
Summarizing current status: QMI/wwan devices supported by the
combination of cdc-wdm and qmi_wwan may present the three QMI/wwan
endpoints as either
a) "CDC Ethernet like":
control interface
interrupt in endpoint
data interface
bulk in endpoint
bulk out endpoint
b) or "Combined":
control/data interface
interrupt in endpoint
bulk in endpoint
bulk out endpoint
"b" gives us no options: A single interface - a single driver. qmi_wwan
matches against the combined control/data interface and loads cdc-wdm as
a subdriver.
When it comes to "a", cdc_wdm matches and binds to the control interface
as an ordinary interface driver and qmi_wwan matches and binds to the
data interface. This strategy does work with the currently supported
devices and has the advantage of a clear interface <-> driver
relationship.
It does have a few disadvantages though, and that's why I bring up this
discussion again:
- product IDs must be added to both cdc-wdm driver and qmi_wwan driver
- probing is different from cdc_ether, which is the model the firmware
is trying to emulate, confusing users
- qmi_wwan must peek at an interface it doesn't drive to pick up
e.g. the MAC address descriptor
- reliable matching against the data interface may be difficult because
the interface descriptors lack unique properties
- coordinated matching between control interface based drivers like
cdc_ether and data interface based drivers like qmi_wwan may be very
difficult (aka "impossible")
The two last points have just been brought to my attention by Andrew.
We currenly have a situation where all Huawei, class COMM, subclass
Ethernet, protocol 255 (sic) devices are bound to cdc-ether. We'd
really like these to be handled by cdc-wdm + qmi_wwan instead. But how?
Transferring the control interface to cdc-wdm is easy. But we need to
make qmi_wwan match the accompanying data interface and *no other* data
interface. How?
The data interfaces have class CDC_DATA, subclass 0, protocol 0 like any
standard compliant CDC data interface. We cannot let qmi_wwan just bind
to any such interface on a Huawei device. That would match a fixed-line
modem with standad CDC ACM, or an Ethernet USB dongle, or whatever.
To solve this problem, qmi_wwan can peek at the descriptors on the
control interface to verify that the data interface is in fact part of a
QMI/wwan interface set. But this is quickly becoming very ugly. What if
we are moving only some of the mentioned devices (because only some of
them support QMI) from cdc_ether to qmi_wwan? You'd then need a control
interface based blacklist in cdc_ether matching a data interface based
rule in qmi_wwan, and having a similar control interface based match
list in cdc-wdm.
So you'd end up having a single QMI/wwan function requiring device ID
entries in 3(!) drivers, using complex probing logic to make it all
work.
IMHO the three endpoints providing a QMI/wwan function should alwasy be
regarded as a single functional unit, whether the firmware decides to
present it as separate control and data interfaces with a CDC Union
descriptor binding them together, or as a single USB interface. The
data interface is a slave interface which should not be driven
independently of the control interface. It's one function, one driver.
Changing qmi_wwan to bind always bind to the control interface will
simplify a number of things:
- no need at all to add QMI devices to cdc-wdm. cdc-wdm will be used
as a subdriver for all QMI devices regardless of descriptor layout
- similar probe logic in cdc_ether and qmi_wwan makes it easy to create
a matching entry and it's inverse, avoiding partially overlapping
matches
- wwanX interfaces would be bound to the control interface regardless
of whether the driver was qmi_wwan, cdc_ether or some other driver,
providing consistency to users and userspace
And these changes are IMHO necessary to reliably and consistenly bind
some devices, like the above mentioned Huawei devices.
So I have ended up with the conclusion that qmi_wwan should bind to the
control interface, and claiming any dedicated data interface just like
cdc_ether does. In fact, I believe we never would have considered
anything else if we had started with the single interface + subdriver
and later added two interface support.
I am going to code up the changes and send as RFC patches, removing the
explicit QMI device matches from cdc_wdm and use the subdriver support
instead.
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
