- 23 1月, 2021 1 次提交
-
-
由 Giacinto Cifelli 提交于
Bus 003 Device 009: ID 1e2d:006f Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1e2d idProduct 0x006f bcdDevice 0.00 iManufacturer 3 Cinterion Wireless Modules iProduct 2 PLSx3 iSerial 4 fa3c1419 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 303 bNumInterfaces 9 bConfigurationValue 1 iConfiguration 1 Cinterion Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC Union: bMasterInterface 0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 3 CDC Union: bMasterInterface 2 bSlaveInterface 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 4 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 5 CDC Union: bMasterInterface 4 bSlaveInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 6 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 7 CDC Union: bMasterInterface 6 bSlaveInterface 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Cc: stable@vger.kernel.org Signed-off-by: NGiacinto Cifelli <gciofono@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20210120045650.10855-1-gciofono@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 21 1月, 2021 1 次提交
-
-
由 Grant Grundler 提交于
RTL8156 sends notifications about every 32ms. Only display/log notifications when something changes. This issue has been reported by others: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832472 https://lkml.org/lkml/2020/8/27/1083 ... [785962.779840] usb 1-1: new high-speed USB device number 5 using xhci_hcd [785962.929944] usb 1-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00 [785962.929949] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [785962.929952] usb 1-1: Product: USB 10/100/1G/2.5G LAN [785962.929954] usb 1-1: Manufacturer: Realtek [785962.929956] usb 1-1: SerialNumber: 000000001 [785962.991755] usbcore: registered new interface driver cdc_ether [785963.017068] cdc_ncm 1-1:2.0: MAC-Address: 00:24:27:88:08:15 [785963.017072] cdc_ncm 1-1:2.0: setting rx_max = 16384 [785963.017169] cdc_ncm 1-1:2.0: setting tx_max = 16384 [785963.017682] cdc_ncm 1-1:2.0 usb0: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, 00:24:27:88:08:15 [785963.019211] usbcore: registered new interface driver cdc_ncm [785963.023856] usbcore: registered new interface driver cdc_wdm [785963.025461] usbcore: registered new interface driver cdc_mbim [785963.038824] cdc_ncm 1-1:2.0 enx002427880815: renamed from usb0 [785963.089586] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected [785963.121673] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected [785963.153682] cdc_ncm 1-1:2.0 enx002427880815: network connection: disconnected ... This is about 2KB per second and will overwrite all contents of a 1MB dmesg buffer in under 10 minutes rendering them useless for debugging many kernel problems. This is also an extra 180 MB/day in /var/logs (or 1GB per week) rendering the majority of those logs useless too. When the link is up (expected state), spew amount is >2x higher: ... [786139.600992] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.632997] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink [786139.665097] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.697100] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink [786139.729094] cdc_ncm 2-1:2.0 enx002427880815: network connection: connected [786139.761108] cdc_ncm 2-1:2.0 enx002427880815: 2500 mbit/s downlink 2500 mbit/s uplink ... Chrome OS cannot support RTL8156 until this is fixed. Signed-off-by: NGrant Grundler <grundler@chromium.org> Reviewed-by: NHayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20210120011208.3768105-1-grundler@chromium.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 15 1月, 2021 1 次提交
-
-
由 Geert Uytterhoeven 提交于
In general, device drivers should not be enabled by default. Fixes: 657bc1d1 ("r8153_ecm: avoid to be prior to r8152 driver") Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210113144309.1384615-1-geert+renesas@glider.beSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 13 1月, 2021 2 次提交
-
-
由 Leon Schuermann 提交于
This commit enables the use of the r8153_ecm driver, introduced with commit c1aedf01 ("net/usb/r8153_ecm: support ECM mode for RTL8153") for the Lenovo Powered USB-C Hub (17ef:721e) based on the Realtek RTL8153B chip. This results in the following driver preference: - if r8152 is available, use the r8152 driver - if r8152 is not available, use the r8153_ecm driver This is done to prevent the NIC from constantly sending pause frames when the host system enters standby (fixed by using the r8152 driver in "r8152: Add Lenovo Powered USB-C Travel Hub"), while still allowing the device to work with the r8153_ecm driver as a fallback. Signed-off-by: NLeon Schuermann <leon@is.currently.online> Tested-by: NLeon Schuermann <leon@is.currently.online> Link: https://lore.kernel.org/r/20210111190312.12589-3-leon@is.currently.onlineSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Leon Schuermann 提交于
This USB-C Hub (17ef:721e) based on the Realtek RTL8153B chip used to use the cdc_ether driver. However, using this driver, with the system suspended the device constantly sends pause-frames as soon as the receive buffer fills up. This causes issues with other devices, where some Ethernet switches stop forwarding packets altogether. Using the Realtek driver (r8152) fixes this issue. Pause frames are no longer sent while the host system is suspended. Signed-off-by: NLeon Schuermann <leon@is.currently.online> Tested-by: NLeon Schuermann <leon@is.currently.online> Link: https://lore.kernel.org/r/20210111190312.12589-2-leon@is.currently.onlineSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 12 1月, 2021 1 次提交
-
-
由 Andrey Zhizhikin 提交于
MSFT ActiveSync implementation requires that the size of the response for incoming query is to be provided in the request input length. Failure to set the input size proper results in failed request transfer, where the ActiveSync counterpart reports the NDIS_STATUS_INVALID_LENGTH (0xC0010014L) error. Set the input size for OID_GEN_PHYSICAL_MEDIUM query to the expected size of the response in order for the ActiveSync to properly respond to the request. Fixes: 039ee17d ("rndis_host: Add RNDIS physical medium checking into generic_rndis_bind()") Signed-off-by: NAndrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com> Link: https://lore.kernel.org/r/20210108095839.3335-1-andrey.zhizhikin@leica-geosystems.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 06 1月, 2021 1 次提交
-
-
由 Jouni K. Seppänen 提交于
Aligning to tx_ndp_modulus is not sufficient because the next align call can be cdc_ncm_align_tail, which can add up to ctx->tx_modulus + ctx->tx_remainder - 1 bytes. This used to lead to occasional crashes on a Huawei 909s-120 LTE module as follows: - the condition marked /* if there is a remaining skb [...] */ is true so the swaps happen - skb_out is set from ctx->tx_curr_skb - skb_out->len is exactly 0x3f52 - ctx->tx_curr_size is 0x4000 and delayed_ndp_size is 0xac (note that the sum of skb_out->len and delayed_ndp_size is 0x3ffe) - the for loop over n is executed once - the cdc_ncm_align_tail call marked /* align beginning of next frame */ increases skb_out->len to 0x3f56 (the sum is now 0x4002) - the condition marked /* check if we had enough room left [...] */ is false so we break out of the loop - the condition marked /* If requested, put NDP at end of frame. */ is true so the NDP is written into skb_out - now skb_out->len is 0x4002, so padding_count is minus two interpreted as an unsigned number, which is used as the length argument to memset, leading to a crash with various symptoms but usually including > Call Trace: > <IRQ> > cdc_ncm_fill_tx_frame+0x83a/0x970 [cdc_ncm] > cdc_mbim_tx_fixup+0x1d9/0x240 [cdc_mbim] > usbnet_start_xmit+0x5d/0x720 [usbnet] The cdc_ncm_align_tail call first aligns on a ctx->tx_modulus boundary (adding at most ctx->tx_modulus-1 bytes), then adds ctx->tx_remainder bytes. Alternatively, the next alignment call can occur in cdc_ncm_ndp16 or cdc_ncm_ndp32, in which case at most ctx->tx_ndp_modulus-1 bytes are added. A similar problem has occurred before, and the code is nontrivial to reason about, so add a guard before the crashing call. By that time it is too late to prevent any memory corruption (we'll have written past the end of the buffer already) but we can at least try to get a warning written into an on-disk log by avoiding the hard crash caused by padding past the buffer with a huge number of zeros. Signed-off-by: NJouni K. Seppänen <jks@iki.fi> Fixes: 4a0e3e98 ("cdc_ncm: Add support for moving NDP to end of NCM frame") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209407Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 1月, 2021 1 次提交
-
-
由 Bjørn Mork 提交于
New modem using ff/ff/30 for QCDM, ff/00/00 for AT and NMEA, and ff/ff/ff for RMNET/QMI. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=0620 Rev= 4.09 S: Manufacturer=Quectel S: Product=EM160R-GL S: SerialNumber=e31cedc1 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20201230152451.245271-1-bjorn@mork.noSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 29 12月, 2020 1 次提交
-
-
由 Roland Dreier 提交于
The cdc_ncm driver passes network connection notifications up to usbnet_link_change(), which is the right place for any logging. Remove the netdev_info() duplicating this from the driver itself. This stops devices such as my "TRENDnet USB 10/100/1G/2.5G LAN" (ID 20f4:e02b) adapter from spamming the kernel log with cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected messages every 60 msec or so. Signed-off-by: NRoland Dreier <roland@kernel.org> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20201224032116.2453938-1-roland@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 10 12月, 2020 1 次提交
-
-
由 Zheng Yongjun 提交于
Replace a comma between expression statements by a semicolon. Signed-off-by: NZheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 11月, 2020 1 次提交
-
-
由 Yves-Alexis Perez 提交于
Starting with iOS 14 released in September 2020, connectivity using the personal hotspot USB tethering function of iOS devices is broken. Communication between the host and the device (for example ICMP traffic or DNS resolution using the DNS service running in the device itself) works fine, but communication to endpoints further away doesn't work. Investigation on the matter shows that no UDP and ICMP traffic from the tethered host is reaching the Internet at all. For TCP traffic there are exchanges between tethered host and server but packets are modified in transit leading to impossible communication. After some trials Matti Vuorela discovered that reducing the URB buffer size by two bytes restored the previous behavior. While a better solution might exist to fix the issue, since the protocol is not publicly documented and considering the small size of the fix, let's do that. Tested-by: NMatti Vuorela <matti.vuorela@bitfactor.fi> Signed-off-by: NYves-Alexis Perez <corsac@corsac.net> Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/ Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038 Link: https://lore.kernel.org/r/20201119172439.94988-1-corsac@corsac.netSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 20 11月, 2020 1 次提交
-
-
由 Hayes Wang 提交于
Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled as modules. Otherwise, the r8153_ecm would be used, even though the device is supported by r8152 driver. Fixes: c1aedf01 ("net/usb/r8153_ecm: support ECM mode for RTL8153") Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NHayes Wang <hayeswang@realtek.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/1394712342-15778-394-Taiwan-albertk@realtek.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 19 11月, 2020 1 次提交
-
-
由 Filip Moc 提交于
LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set. Signed-off-by: NFilip Moc <dev@moc6.cz> Acked-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20201117173631.GA550981@moc6.czSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 17 11月, 2020 1 次提交
-
-
由 Zhang Changzhong 提交于
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: ca139d76 ("cx82310_eth: re-enable ethernet mode after router reboot") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1605247627-15385-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 13 11月, 2020 3 次提交
-
-
由 Heiner Kallweit 提交于
Replace usbnet_get_stats64() with new identical core function dev_get_tstats64() in all users and remove usbnet_get_stats64(). Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Heiner Kallweit 提交于
Use netdev->tstats instead of a member of usbnet for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Heiner Kallweit 提交于
Use netdev->tstats instead of a member of qmimux_priv for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 08 11月, 2020 1 次提交
-
-
由 Wang Qing 提交于
Actually, withing should be within. Signed-off-by: NWang Qing <wangqing@vivo.com> Link: https://lore.kernel.org/r/1604649025-22559-1-git-send-email-wangqing@vivo.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 06 11月, 2020 1 次提交
-
-
由 Hayes Wang 提交于
Support ECM mode based on cdc_ether with relative mii functions, when CONFIG_USB_RTL8152 is not set, or the device is not supported by r8152 driver. Both r8152 and r8153_ecm would check the return value of rtl8152_get_version() in porbe(). If rtl8152_get_version() return none zero value, the r8152 is used for the device with vendor mode. Otherwise, the r8153_ecm is used for the device with ECM mode. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/1394712342-15778-392-Taiwan-albertk@realtek.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 04 11月, 2020 4 次提交
-
-
由 Lee Jones 提交于
Fixes the following W=1 kernel build warning(s): drivers/net/usb/r8152.c:992: warning: Function parameter or member 'mode_pre' not described in 'fw_phy_nc' drivers/net/usb/r8152.c:992: warning: Function parameter or member 'mode_post' not described in 'fw_phy_nc' Signed-off-by: NLee Jones <lee.jones@linaro.org> Acked-by: NHayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20201102114512.1062724-28-lee.jones@linaro.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Lee Jones 提交于
Fixes the following W=1 kernel build warning(s): drivers/net/usb/lan78xx.c: In function ‘lan78xx_read_raw_otp’: drivers/net/usb/lan78xx.c:825:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_write_raw_otp’: drivers/net/usb/lan78xx.c:879:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_deferred_multicast_write’: drivers/net/usb/lan78xx.c:1041:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_update_flowcontrol’: drivers/net/usb/lan78xx.c:1127:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_init_mac_address’: drivers/net/usb/lan78xx.c:1666:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_link_status_change’: drivers/net/usb/lan78xx.c:1841:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_irq_bus_sync_unlock’: drivers/net/usb/lan78xx.c:1920:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan8835_fixup’: drivers/net/usb/lan78xx.c:1994:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_rx_max_frame_length’: drivers/net/usb/lan78xx.c:2192:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_change_mtu’: drivers/net/usb/lan78xx.c:2270:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_mac_addr’: drivers/net/usb/lan78xx.c:2299:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_features’: drivers/net/usb/lan78xx.c:2333:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/usb/lan78xx.c: In function ‘lan78xx_set_suspend’: drivers/net/usb/lan78xx.c:3807:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Signed-off-by: NLee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201102114512.1062724-25-lee.jones@linaro.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Lee Jones 提交于
Fixes the following W=1 kernel build warning(s): drivers/net/usb/r8152.c:934: warning: Function parameter or member 'blk_hdr' not described in 'fw_mac' drivers/net/usb/r8152.c:934: warning: Function parameter or member 'reserved' not described in 'fw_mac' drivers/net/usb/r8152.c:947: warning: Function parameter or member 'blk_hdr' not described in 'fw_phy_patch_key' drivers/net/usb/r8152.c:947: warning: Function parameter or member 'reserved' not described in 'fw_phy_patch_key' drivers/net/usb/r8152.c:986: warning: Function parameter or member 'blk_hdr' not described in 'fw_phy_nc' drivers/net/usb/r8152.c:986: warning: Function parameter or member 'mode_pre' not described in 'fw_phy_nc' drivers/net/usb/r8152.c:986: warning: Function parameter or member 'mode_post' not described in 'fw_phy_nc' drivers/net/usb/r8152.c:986: warning: Function parameter or member 'reserved' not described in 'fw_phy_nc' Signed-off-by: NLee Jones <lee.jones@linaro.org> Acked-by: NHayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20201102114512.1062724-23-lee.jones@linaro.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Daniele Palmas 提交于
Add support for Telit LE910Cx 0x1230 composition: 0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty Signed-off-by: NDaniele Palmas <dnlplm@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20201102110108.17244-1-dnlplm@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 19 10月, 2020 1 次提交
-
-
由 Anant Thazhemadam 提交于
In set_ethernet_addr(), if get_registers() succeeds, the ethernet address that was read must be copied over. Otherwise, a random ethernet address must be assigned. get_registers() returns 0 if successful, and negative error number otherwise. However, in set_ethernet_addr(), this return value is incorrectly checked. Since this return value will never be equal to sizeof(node_id), a random MAC address will always be generated and assigned to the device; even in cases when get_registers() is successful. Correctly modifying the condition that checks if get_registers() was successful or not fixes this problem, and copies the ethernet address appropriately. Fixes: b2a0f274 ("net: rtl8150: Use the new usb control message API.") Signed-off-by: NAnant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20201011173030.141582-1-anant.thazhemadam@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 14 10月, 2020 2 次提交
-
-
由 Heiner Kallweit 提交于
Simplify the code by using new function dev_fetch_sw_netstats(). Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/70ad3e33-8ea6-e12e-31de-5fec7a3c4f6e@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Heiner Kallweit 提交于
Simplify the code by using new function dev_fetch_sw_netstats(). Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/2c97b75b-107e-0ab6-d9ef-9f38bb03f495@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 13 10月, 2020 2 次提交
-
-
由 Ondrej Zary 提交于
Use netdev_err for better device identification in syslog. Signed-off-by: NOndrej Zary <linux@zary.sk> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Ondrej Zary 提交于
When the router is rebooted without a power cycle, the USB device remains connected but its configuration is reset. This results in a non-working ethernet connection with messages like this in syslog: usb 2-2: RX packet too long: 65535 B Re-enable ethernet mode when receiving a packet with invalid size of 0xffff. Signed-off-by: NOndrej Zary <linux@zary.sk> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 11 10月, 2020 1 次提交
-
-
由 Heiner Kallweit 提交于
Obviously this driver version doesn't make sense. Go with the default and let ethtool display the kernel version. Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 09 10月, 2020 1 次提交
-
-
由 Wilken Gottwalt 提交于
Add usb ids of the Cellient MPL200 card. Signed-off-by: NWilken Gottwalt <wilken.gottwalt@mailbox.org> Acked-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 06 10月, 2020 1 次提交
-
-
由 Anant Thazhemadam 提交于
When get_registers() fails in set_ethernet_addr(),the uninitialized value of node_id gets copied over as the address. So, check the return value of get_registers(). If get_registers() executed successfully (i.e., it returns sizeof(node_id)), copy over the MAC address using ether_addr_copy() (instead of using memcpy()). Else, if get_registers() failed instead, a randomly generated MAC address is set as the MAC address instead. Reported-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com Tested-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com Acked-by: NPetko Manolov <petkan@nucleusys.com> Signed-off-by: NAnant Thazhemadam <anant.thazhemadam@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 10月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
Replace // FALLTHROUGH comment with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 03 10月, 2020 2 次提交
-
-
由 Łukasz Stelmach 提交于
Use more generic eth_platform_get_mac_address() which can get a MAC address from other than DT platform specific sources too. Check if the obtained address is valid. Signed-off-by: NŁukasz Stelmach <l.stelmach@samsung.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Petko Manolov 提交于
v2: If reading the MAC address from eeprom fail don't throw an error, use randomly generated MAC instead. Either way the adapter will soldier on and the return type of set_ethernet_addr() can be reverted to void. v1: Fix a bug in set_ethernet_addr() which does not take into account possible errors (or partial reads) returned by its helpers. This can potentially lead to writing random data into device's MAC address registers. Signed-off-by: NPetko Manolov <petko.manolov@konsulko.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 10月, 2020 2 次提交
-
-
由 Petko Manolov 提交于
The old usb_control_msg() let the caller handle the error and also did not account for partial reads. Since these are now considered harmful, move the driver over to usb_control_msg_recv/send() calls. Added small note about why set_registers() can't be used to substitute set_register(). Signed-off-by: NPetko Manolov <petko.manolov@konsulko.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20200927124909.16380-2-petko.manolov@konsulko.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Petko Manolov 提交于
The old usb_control_msg() let the caller handle the error and also did not account for partial reads. Since these are now considered harmful, move the driver over to usb_control_msg_recv/send() calls. Signed-off-by: NPetko Manolov <petko.manolov@konsulko.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20200927124909.16380-3-petko.manolov@konsulko.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 30 9月, 2020 3 次提交
-
-
The comment above nc_vendor_write() suggests that the function could become async so that is usable in `in_interrupt()' context or that it already is safe to be called from such a context. Eitherway: The function did not become async since v2.4.9.2 (2002) and it must be not be called from `in_interrupt()' context because it sleeps on mutltiple occations. Remove the misleading comment. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
kaweth_async_set_rx_mode() invokes kaweth_contol() and has two callers: - kaweth_open() which is invoked from preemptible context . - kaweth_start_xmit() which holds a spinlock and has bottom halfs disabled. If called from kaweth_start_xmit() kaweth_async_set_rx_mode() obviously cannot block, which means it can't call kaweth_control(). This is detected with an in_interrupt() check. Replace the in_interrupt() check in kaweth_async_set_rx_mode() with an argument which is set true by the caller if the context is safe to sleep, otherwise false. Now kaweth_control() is only called from preemptible context which means there is no need for GFP_ATOMIC allocations anymore. Replace it with usb_control_msg(). Cleanup the code a bit while at it. Finally remove kaweth_control() since the last user is gone. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
kaweth_control() is almost the same as usb_control_msg() except for the memory allocation mode (GFP_ATOMIC vs GFP_NOIO) and the in_interrupt() check. All the invocations of kaweth_control() are within the probe function in fully preemtible context so there is no reason to use atomic allocations, GFP_NOIO which is used by usb_control_msg() is perfectly fine. Replace kaweth_control() invocations from probe with usb_control_msg(). Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 9月, 2020 1 次提交
-
-
由 Wilken Gottwalt 提交于
Adds the driver_info and usb ids of the AX88179 based MCT U3-A9003 USB 3.0 ethernet adapter. Signed-off-by: NWilken Gottwalt <wilken.gottwalt@mailbox.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-