Marcel Holtmann <marcel@xxxxxxxxxxxx> writes: >> Try the data format thing. I don't think that's a firmware bug really, >> but simply that you didn't set the format first. The UML290 sends this >> command to ensure the data format is always [ no QoS, raw IP ]. > > I rather have these all running in raw IP mode. The 802.3 framing is > utterly stupid. I tend to agree. It's a stupid hack to avoid fixing the host/driver. The ethernet header doesn't add any value to neither host nor device. But I believe you will have to fix some issues like the IPv6 stack expecting a mac address and such before you can make it fly. Or let the driver add/strip the ethernet header. Might be easier, but doesn't entirely get rid of the hack. Makes the device work in both modes though, and it does avoid using USB bandwith and device CPU for useless headers, so it is still a gain. Doing something with the raw IP mode is definitely on my wishlist, but it doesn't have high priority at the moment. I had a quick look at the Android rmnet driver and believe most of what's needed is there already. It's just a matter of splitting out the parts we need, and getting the IP ARPHDR stuff integrated. Right... > The only reason why people do 802.3, because that is the only way to > make DHCP work in most operating system. And in Linux that is even true > for dhclient. Yeah, and then we meet the question of whether the driver should "fix" this or if that fix needs to go into every userspace app. I believe a limited driver fix is better as it will make every legacy app just work. > Actually the USB CDC usage with USB_CDC_SEND_ENCAPSULATED_COMMAND and > USB_CDC_GET_ENCAPSULATED_RESPONSE is pretty much a standard. It is just > that bNotificationType with USB_CDC_NOTIFY_RESPONSE_AVAILABLE is a bit > of funky way of doing things in the first place. > > However all not handled responses could be just forwarded to userspace > as they are. And kernel drivers claiming some responses can just keep > consuming them. For example USB_CDC_NOTIFY_NETWORK_CONNECTION can be > still handled inside the driver. That is my working plan, and that is what cdc-wdm currently does as long as the device exports a dedicated "device management" interface. The only issue that needs to be fixed is making cdc-wdm share an usb interface with a network driver. A little tricky as they must share the interrupt endpoint, but not at all impossible. I also intend to add the bare minimum of the embedded QMI to the driver to allow "ip link set dev wwanX up" to Just Work(tm). I consider that much the same as configuring the registers of your PCI ethernet device to allow it to get link. You do *not* want to run a userspace app with detailed knowledge of your PCI ethernet device just to get a link, do you? 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
