kernel/linux.git/drivers/usb/gadget/function/u_ether.c, branch linux-6.0.y

usb: gadget: u_ether: Remove duplicated include in u_ether.c

2022-06-24T11:42:17+00:00

Fix following includecheck warning: ./drivers/usb/gadget/function/u_ether.c: linux/etherdevice.h is included more than once. Signed-off-by: Yang Li Link: https://lore.kernel.org/r/20220623010808.9816-1-yang.lee@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: fix regression in setting fixed MAC address

2022-06-10T09:12:53+00:00

In systemd systems setting a fixed MAC address through the "dev_addr" module argument fails systematically. When checking the MAC address after the interface is created it always has the same but different MAC address to the one supplied as argument. This is partially caused by systemd which by default will set an internally generated permanent MAC address for interfaces that are marked as having a randomly generated address. Commit 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") didn't take into account the fact that the interface must be marked as having a set MAC address when it's set as module argument. Fixed by marking the interface with NET_ADDR_SET when the "dev_addr" module argument is supplied. Fixes: 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") Cc: stable@vger.kernel.org Signed-off-by: Marian Postevca Link: https://lore.kernel.org/r/20220603153459.32722-1-posteuca@mutex.one Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: fix race in setting MAC address in setup phase

2021-12-13T14:22:23+00:00

When listening for notifications through netlink of a new interface being registered, sporadically, it is possible for the MAC to be read as zero. The zero MAC address lasts a short period of time and then switches to a valid random MAC address. This causes problems for netd in Android, which assumes that the interface is malfunctioning and will not use it. In the good case we get this log: InterfaceController::getCfg() ifName usb0 hwAddr 92:a8:f0:73:79:5b ipv4Addr 0.0.0.0 flags 0x1002 In the error case we get these logs: InterfaceController::getCfg() ifName usb0 hwAddr 00:00:00:00:00:00 ipv4Addr 0.0.0.0 flags 0x1002 netd : interfaceGetCfg("usb0") netd : interfaceSetCfg() -> ServiceSpecificException (99, "[Cannot assign requested address] : ioctl() failed") The reason for the issue is the order in which the interface is setup, it is first registered through register_netdev() and after the MAC address is set. Fixed by first setting the MAC address of the net_device and after that calling register_netdev(). Fixes: bcd4a1c40bee885e ("usb: gadget: u_ether: construct with default values and add setters/getters") Cc: stable@vger.kernel.org Signed-off-by: Marian Postevca Link: https://lore.kernel.org/r/20211204214912.17627-1-posteuca@mutex.one Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: use eth_hw_addr_set()

2021-10-20T17:31:50+00:00

Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Reviewed-by: Maciej Żenczykowski Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20211019172124.1413620-1-kuba@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: fix a potential null pointer dereference

2021-07-21T08:04:19+00:00

f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile Cc: "Bryan O'Donoghue" Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: support configuring interface names.

2021-01-15T15:08:53+00:00

This patch allows the administrator to configure the interface name of a function using u_ether (e.g., eem, ncm, rndis). Currently, all such interfaces, regardless of function type, are always called usb0, usb1, etc. This makes it very cumbersome to use more than one such type at a time, because userspace cannnot easily tell the interfaces apart and apply the right configuration to each one. Interface renaming in userspace based on driver doesn't help, because the interfaces all have the same driver. Without this patch, doing this require hacks/workarounds such as setting fixed MAC addresses on the functions, and then renaming by MAC address, or scraping configfs after each interface is created to find out what it is. Setting the interface name is done by writing to the same "ifname" configfs attribute that reports the interface name after the function is bound. The write must contain an interface pattern such as "usb%d" (which will cause the net core to pick the next available interface name starting with "usb"). This patch does not allow writing an exact interface name (as opposed to a pattern) because if the interface already exists at bind time, the bind will fail and the whole gadget will fail to activate. This could be allowed in a future patch. For compatibility with current userspace, when reading an ifname that has not currently been set, the result is still "(unnamed net_device)". Once a write to ifname happens, then reading ifname will return whatever was last written. Tested by configuring an rndis function and an ncm function on the same gadget, and writing "rndis%d" to ifname on the rndis function and "ncm%d" to ifname on the ncm function. When the gadget was bound, the rndis interface was rndis0 and the ncm interface was ncm0. Signed-off-by: Lorenzo Colitti Link: https://lore.kernel.org/r/20210113234222.3272933-1-lorenzo@google.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: Fix MTU size mismatch with RX packet size

2020-12-28T14:45:51+00:00

Fix the MTU size issue with RX packet size as the host sends the packet with extra bytes containing ethernet header. This causes failure when user sets the MTU size to the maximum i.e. 15412. In this case the ethernet packet received will be of length 15412 plus the ethernet header length. This patch fixes the issue where there is a check that RX packet length must not be more than max packet length. Fixes: bba787a860fa ("usb: gadget: ether: Allow jumbo frames") Signed-off-by: Manish Narani Cc: stable Link: https://lore.kernel.org/r/1605597215-122027-1-git-send-email-manish.narani@xilinx.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: enable qmult on SuperSpeed Plus as well

2020-10-02T06:57:41+00:00

The u_ether driver has a qmult setting that multiplies the transmit queue length (which by default is 2). The intent is that it should be enabled at high/super speed, but because the code does not explicitly check for USB_SUPER_PLUS, it is disabled at that speed. Fix this by ensuring that the queue multiplier is enabled for any wired link at high speed or above. Using >= for USB_SPEED_* constants seems correct because it is what the gadget_is_xxxspeed functions do. The queue multiplier substantially helps performance at higher speeds. On a direct SuperSpeed Plus link to a Linux laptop, iperf3 single TCP stream: Before (qmult=1): 1.3 Gbps After (qmult=5): 3.2 Gbps Fixes: 04617db7aa68 ("usb: gadget: add SS descriptors to Ethernet gadget") Reviewed-by: Maciej Żenczykowski Signed-off-by: Lorenzo Colitti Signed-off-by: Felipe Balbi

usb: gadget: Use fallthrough pseudo-keyword

2020-07-10T06:55:18+00:00

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20200707171500.GA13620@embeddedor Signed-off-by: Greg Kroah-Hartman

usb: gadget: function: u_ether: Downgrade kerneldoc headers which to not make the mark

2020-07-09T15:19:56+00:00

Kerneldoc expects all function arguments to be documented. If any are missed it will complain. Downgrade one header with 3 missing argument descriptions and one which makes no attempt. Fixes the following W=1 kernel build warning(s): drivers/usb/gadget/function/u_ether.c:750: warning: Function parameter or member 'dev_addr' not described in 'gether_setup_name' drivers/usb/gadget/function/u_ether.c:750: warning: Function parameter or member 'host_addr' not described in 'gether_setup_name' drivers/usb/gadget/function/u_ether.c:750: warning: Function parameter or member 'qmult' not described in 'gether_setup_name' drivers/usb/gadget/function/u_ether.c:1022: warning: Function parameter or member 'dev' not described in 'gether_cleanup' Cc: Felipe Balbi Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200706133341.476881-6-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman