From: David S. Miller Date: Fri, 4 Dec 2015 21:56:23 +0000 (-0500) Subject: Merge branch 'qmi_wwan_MDM9x30' X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=2141eaf0e896990ef1042f5bf558935523da69e9;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git Merge branch 'qmi_wwan_MDM9x30' Bjørn Mork says: ==================== net: qmi_wwan: MDM9x30 support We add new device IDs all the time, often without any testing on actual hardware. This is usually OK as long as the device is similar to already supported devices, using the same chipset and firmware basis. But the Sierra Wireless MC7455 is an example of a new chipset generation. Adding it based on assumed similarity with its ancestors proved too optimistic. This series adds the missing bits and pieces necessary to support LTE Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to Sierra Wireless for providing MC7455 samples for testing The most important change is the "raw-ip" support. The series also adds a necessary control request, removes an unsupported device ID, and adds a driver specific entry in MAINTAINERS. A few random notes about "raw-ip": "I rather have these all running in raw IP mode. The 802.3 framing is utterly stupid." - Marcel Holtmann in Jan 2012 [1] Marcel was right. I should have listened to him. What more can I say? The 802.3 framing has provided a steady supply of firmware bugs for many years. We've added driver workarounds for many of these, but there are still known bugs where the workaround is so yucky that we have refused to apply it. But all that is over now. The latest generation Qualcomm chips no longer supports 802.3 framing at all. I had two open questions regarding the "raw-ip" userspace API: 1) Should we continue faking an ethernet device, even if we don't use the L2 headers on the USB link anymore? There was a vote in favour of the "headerless" device. This is the honest representation of the hardware/firmware interface. 2) What input should the driver base its framing on? Snooping or directly manipulating QMI is considered out of the question. We delegated all QMI handling to userspace from the beginning. We have so far required userspace to configure the firmware for "802.3" framing, or fail if that proved impossible. This requirement is now changed. Userspace must now inform the driver if it negotiates "raw-ip" framing. Two alternative interfaces were proposed: - ethtool private driver flag, or - sysfs file The NetworkManager/ModemManager developers were in favour of the sysfs alternative. These questions (or any other you migh have :) are of course still open. This patch set presents the solutions I currently prefer, considering the above. All comments are appreciated, even simple '+1' ones. ==================== Signed-off-by: David S. Miller --- 2141eaf0e896990ef1042f5bf558935523da69e9