kernel/drivers/net/usb/cdc_ncm.c, branch linux-4.3.y

net: cdc_ncm: avoid changing RX/TX buffers on MTU changes

2016-01-31T19:25:49Z

[ Upstream commit 1dfddff5fcd869fcab0c52fafae099dfa435a935 ] NCM buffer sizes are negotiated with the device independently of the network device MTU. The RX buffers are allocated by the usbnet framework based on the rx_urb_size value set by cdc_ncm. A single RX buffer can hold a number of MTU sized packets. The default usbnet change_mtu ndo only modifies rx_urb_size if it is equal to hard_mtu. And the cdc_ncm driver will set rx_urb_size and hard_mtu independently of each other, based on dwNtbInMaxSize and dwNtbOutMaxSize respectively. It was therefore assumed that usbnet_change_mtu() would never touch rx_urb_size. This failed to consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens to be equal. Fix by implementing an NCM specific change_mtu ndo, modifying the netdev MTU without touching the buffer size settings. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: cdc_mbim: add "NDP to end" quirk for Huawei E3372

2016-01-23T04:55:45Z

[ Upstream commit f8c0cfa5eca902d388c0b57c7ca29a1ff2e6d8c6 ] The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode as well. Allow this by forcing the NTB to contain only a single NDP, and add a device specific entry for this ID. Due to the way Huawei use device IDs, this might be applied to other modems as well. It is assumed that those modems will be based on the same firmware and will need this quirk too. If not, it will still not harm normal usage, although multiplexing performance could be impacted. Cc: Enrico Mioso Reported-by: Sami Farin Signed-off-by: Bjørn Mork Acked-By: Enrico Mioso Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

cdc_ncm: update specs URL

2015-07-12T04:12:23Z

Update referenced specs link to reflect actual file version and location. Signed-off-by: Enrico Mioso Signed-off-by: David S. Miller

cdc_ncm: Add support for moving NDP to end of NCM frame

2015-07-09T21:58:31Z

NCM specs are not actually mandating a specific position in the frame for the NDP (Network Datagram Pointer). However, some Huawei devices will ignore our aggregates if it is not placed after the datagrams it points to. Add support for doing just this, in a per-device configurable way. While at it, update NCM subdrivers, disabling this functionality in all of them, except in huawei_cdc_ncm where it is enabled instead. We aren't making any distinction between different Huawei NCM devices, based on what the vendor driver does. Standard NCM devices are left unaffected: if they are compliant, they should be always usable, still stay on the safe side. This change has been tested and working with a Huawei E3131 device (which works regardless of NDP position), a Huawei E3531 (also working both ways) and an E3372 (which mandates NDP to be after indexed datagrams). V1->V2: - corrected wrong NDP acronym definition - fixed possible NULL pointer dereference - patch cleanup V2->V3: - Properly account for the NDP size when writing new packets to SKB Signed-off-by: Enrico Mioso Signed-off-by: David S. Miller

cdc_ncm: Fix tx_bytes statistics

2015-05-22T18:26:31Z

The tx_curr_frame_payload field is u32. When we try to calculate a small negative delta based on it, we end up with a positive integer close to 2^32 instead. So the tx_bytes pointer increases by about 2^32 for every transmitted frame. Fix by calculating the delta as a signed long. Cc: Ben Hutchings Reported-by: Florian Bruhin Fixes: 7a1e890e2168 ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller

usbnet: Fix tx_bytes statistic running backward in cdc_ncm

2015-03-29T19:06:45Z

cdc_ncm disagrees with usbnet about how much framing overhead should be counted in the tx_bytes statistics, and tries 'fix' this by decrementing tx_bytes on the transmit path. But statistics must never be decremented except due to roll-over; this will thoroughly confuse user-space. Also, tx_bytes is only incremented by usbnet in the completion path. Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a tx_bytes delta along with the tx_packets count. Fixes: beeecd42c3b4 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics") Signed-off-by: Ben Hutchings Signed-off-by: Bjørn Mork

usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers

2015-03-29T19:06:43Z

Currently the usbnet core does not update the tx_packets statistic for drivers with FLAG_MULTI_PACKET and there is no hook in the TX completion path where they could do this. cdc_ncm and dependent drivers are bumping tx_packets stat on the transmit path while asix and sr9800 aren't updating it at all. Add a packet count in struct skb_data so these drivers can fill it in, initialise it to 1 for other drivers, and add the packet count to the tx_packets statistic on completion. Signed-off-by: Ben Hutchings Tested-by: Bjørn Mork Signed-off-by: David S. Miller

net: cdc_ncm: allow tuning min_tx_pkt

2014-06-02T23:01:31Z

The min_tx_pkt variable decides the cutoff point where the driver will stop padding out NTBs to maximum size. The padding is a tradeoff where we use some USB bus bandwidth to allow the device to receive fixed size buffers. Different devices will have different optimal settings, spanning from no padding at all to padding every NTB. There is no way to automatically figure out which setting is best for a specific device. The default value is a reasonable tradeoff, calculated based on the USB packet size and out NTB max size. This may have to be changed along with any tx_max changes. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller

net: cdc_ncm: export NCM Transfer Block (NTB) parameters

2014-06-02T23:01:31Z

The mandatory GetNtbParameters control request is an important part of the host <-> device protocol negotiation in CDC NCM (and CDC MBIM). It gives device limits which the host must obey when configuring the protocol aggregation variables. The driver will enforce this by rejecting attempts to set any of the tunable variables to a value which is not supported by the device. Exporting the parameter block helps userspace decide which values are allowed without resorting to trial and error. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller

net: cdc_ncm: drop ethtool coalesce support

2014-06-02T23:01:30Z

The ethtool coalesce API is not applicable for this driver. Forcing it to fit the NCM aggregation redefined the API in a driver specific way, which is much worse than defining a clean new API. These ethtool coalesce functions have therefore been replaced by a new sysfs API. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller