<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/usb, branch for-next</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=for-next</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=for-next'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2025-01-10T13:59:20Z</updated>
<entry>
<title>Merge tag 'usb-serial-6.13-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus</title>
<updated>2025-01-10T13:59:20Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2025-01-10T13:59:20Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f3149ed697dd0c4fc1d696fef78129fa2fe4ca12'/>
<id>urn:sha1:f3149ed697dd0c4fc1d696fef78129fa2fe4ca12</id>
<content type='text'>
Johan writes:

USB-serial device ids for 6.13-rc7

Here are some new modem and cp210x device ids.

All have been in linux-next with no reported issues.

* tag 'usb-serial-6.13-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: option: add Neoway N723-EA support
  USB: serial: option: add MeiG Smart SRM815
  USB: serial: cp210x: add Phoenix Contact UPS Device
</content>
</entry>
<entry>
<title>USB: serial: option: add Neoway N723-EA support</title>
<updated>2025-01-08T10:49:54Z</updated>
<author>
<name>Michal Hrusecky</name>
<email>michal.hrusecky@turris.com</email>
</author>
<published>2025-01-07T16:08:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f5b435be70cb126866fa92ffc6f89cda9e112c75'/>
<id>urn:sha1:f5b435be70cb126866fa92ffc6f89cda9e112c75</id>
<content type='text'>
Update the USB serial option driver to support Neoway N723-EA.

ID 2949:8700 Marvell Mobile Composite Device Bus

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(&gt;ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2949 ProdID=8700 Rev= 1.00
S:  Manufacturer=Marvell
S:  Product=Mobile Composite Device Bus
S:  SerialNumber=200806006809080000
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0e(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Tested successfully connecting to the Internet via rndis interface after
dialing via AT commands on If#=4 or If#=6.

Not sure of the purpose of the other serial interface.

Signed-off-by: Michal Hrusecky &lt;michal.hrusecky@turris.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
</content>
</entry>
<entry>
<title>USB: serial: option: add MeiG Smart SRM815</title>
<updated>2025-01-08T10:40:38Z</updated>
<author>
<name>Chukun Pan</name>
<email>amadeus@jmu.edu.cn</email>
</author>
<published>2024-12-15T10:00:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c1947d244f807b1f95605b75a4059e7b37b5dcc3'/>
<id>urn:sha1:c1947d244f807b1f95605b75a4059e7b37b5dcc3</id>
<content type='text'>
It looks like SRM815 shares ID with SRM825L.

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=00(&gt;ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2dee ProdID=4d22 Rev= 4.14
S:  Manufacturer=MEIG
S:  Product=LTE-A Module
S:  SerialNumber=123456
C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Chukun Pan &lt;amadeus@jmu.edu.cn&gt;
Link: https://lore.kernel.org/lkml/20241215100027.1970930-1-amadeus@jmu.edu.cn/
Link: https://lore.kernel.org/all/4333b4d0-281f-439d-9944-5570cbc4971d@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
</content>
</entry>
<entry>
<title>USB: serial: cp210x: add Phoenix Contact UPS Device</title>
<updated>2025-01-08T10:25:47Z</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2025-01-08T10:24:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=854eee93bd6e3dca619d47087af4d65b2045828e'/>
<id>urn:sha1:854eee93bd6e3dca619d47087af4d65b2045828e</id>
<content type='text'>
Phoenix Contact sells UPS Quint devices [1] with a custom datacable [2]
that embeds a Silicon Labs converter:

Bus 001 Device 003: ID 1b93:1013 Silicon Labs Phoenix Contact UPS Device
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1b93
  idProduct          0x1013
  bcdDevice            1.00
  iManufacturer           1 Silicon Labs
  iProduct                2 Phoenix Contact UPS Device
  iSerial                 3 &lt;redacted&gt;
  bNumConfigurations	 1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              2 Phoenix Contact UPS Device
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

[1] https://www.phoenixcontact.com/en-pc/products/power-supply-unit-quint-ps-1ac-24dc-10-2866763
[2] https://www.phoenixcontact.com/en-il/products/data-cable-preassembled-ifs-usb-datacable-2320500

Reported-by: Giuseppe Corbelli &lt;giuseppe.corbelli@antaresvision.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control()</title>
<updated>2025-01-07T10:43:08Z</updated>
<author>
<name>GONG Ruiqi</name>
<email>gongruiqi1@huawei.com</email>
</author>
<published>2025-01-07T01:57:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b0e525d7a22ea350e75e2aec22e47fcfafa4cacd'/>
<id>urn:sha1:b0e525d7a22ea350e75e2aec22e47fcfafa4cacd</id>
<content type='text'>
The error handling for the case `con_index == 0` should involve dropping
the pm usage counter, as ucsi_ccg_sync_control() gets it at the
beginning. Fix it.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: e56aac6e5a25 ("usb: typec: fix potential array underflow in ucsi_ccg_sync_control()")
Signed-off-by: GONG Ruiqi &lt;gongruiqi1@huawei.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20250107015750.2778646-1-gongruiqi1@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb-storage: Add max sectors quirk for Nokia 208</title>
<updated>2025-01-07T10:42:42Z</updated>
<author>
<name>Lubomir Rintel</name>
<email>lrintel@redhat.com</email>
</author>
<published>2025-01-01T21:22:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cdef30e0774802df2f87024d68a9d86c3b99ca2a'/>
<id>urn:sha1:cdef30e0774802df2f87024d68a9d86c3b99ca2a</id>
<content type='text'>
This fixes data corruption when accessing the internal SD card in mass
storage mode.

I am actually not too sure why. I didn't figure a straightforward way to
reproduce the issue, but i seem to get garbage when issuing a lot (over 50)
of large reads (over 120 sectors) are done in a quick succession. That is,
time seems to matter here -- larger reads are fine if they are done with
some delay between them.

But I'm not great at understanding this sort of things, so I'll assume
the issue other, smarter, folks were seeing with similar phones is the
same problem and I'll just put my quirk next to theirs.

The "Software details" screen on the phone is as follows:

  V 04.06
  07-08-13
  RM-849
  (c) Nokia

TL;DR version of the device descriptor:

  idVendor           0x0421 Nokia Mobile Phones
  idProduct          0x06c2
  bcdDevice            4.06
  iManufacturer           1 Nokia
  iProduct                2 Nokia 208

The patch assumes older firmwares are broken too (I'm unable to test, but
no biggie if they aren't I guess), and I have no idea if newer firmware
exists.

Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Cc: stable &lt;stable@kernel.org&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Link: https://lore.kernel.org/r/20250101212206.2386207-1-lkundrak@v3.sk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: midi2: Reverse-select at the right place</title>
<updated>2025-01-07T10:42:22Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2025-01-01T13:11:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6f660ffce7c938f2a5d8473c0e0b45e4fb25ef7f'/>
<id>urn:sha1:6f660ffce7c938f2a5d8473c0e0b45e4fb25ef7f</id>
<content type='text'>
We should do reverse selection of other components from
CONFIG_USB_F_MIDI2 which is tristate, instead of
CONFIG_USB_CONFIGFS_F_MIDI2 which is bool, for satisfying subtle
module dependencies.

Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://lore.kernel.org/r/20250101131124.27599-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Remove WARN_ON in functionfs_bind</title>
<updated>2024-12-23T17:54:34Z</updated>
<author>
<name>Akash M</name>
<email>akash.m5@samsung.com</email>
</author>
<published>2024-12-19T12:52:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dfc51e48bca475bbee984e90f33fdc537ce09699'/>
<id>urn:sha1:dfc51e48bca475bbee984e90f33fdc537ce09699</id>
<content type='text'>
This commit addresses an issue related to below kernel panic where
panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON
in functionsfs_bind, which easily leads to the following scenarios.

1.adb_write in adbd               2. UDC write via configfs
  =================	             =====================

-&gt;usb_ffs_open_thread()           -&gt;UDC write
 -&gt;open_functionfs()               -&gt;configfs_write_iter()
  -&gt;adb_open()                      -&gt;gadget_dev_desc_UDC_store()
   -&gt;adb_write()                     -&gt;usb_gadget_register_driver_owner
                                      -&gt;driver_register()
-&gt;StartMonitor()                       -&gt;bus_add_driver()
 -&gt;adb_read()                           -&gt;gadget_bind_driver()
&lt;times-out without BIND event&gt;           -&gt;configfs_composite_bind()
                                          -&gt;usb_add_function()
-&gt;open_functionfs()                        -&gt;ffs_func_bind()
 -&gt;adb_open()                               -&gt;functionfs_bind()
                                       &lt;ffs-&gt;state !=FFS_ACTIVE&gt;

The adb_open, adb_read, and adb_write operations are invoked from the
daemon, but trying to bind the function is a process that is invoked by
UDC write through configfs, which opens up the possibility of a race
condition between the two paths. In this race scenario, the kernel panic
occurs due to the WARN_ON from functionfs_bind when panic_on_warn is
enabled. This commit fixes the kernel panic by removing the unnecessary
WARN_ON.

Kernel panic - not syncing: kernel: panic_on_warn set ...
[   14.542395] Call trace:
[   14.542464]  ffs_func_bind+0x1c8/0x14a8
[   14.542468]  usb_add_function+0xcc/0x1f0
[   14.542473]  configfs_composite_bind+0x468/0x588
[   14.542478]  gadget_bind_driver+0x108/0x27c
[   14.542483]  really_probe+0x190/0x374
[   14.542488]  __driver_probe_device+0xa0/0x12c
[   14.542492]  driver_probe_device+0x3c/0x220
[   14.542498]  __driver_attach+0x11c/0x1fc
[   14.542502]  bus_for_each_dev+0x104/0x160
[   14.542506]  driver_attach+0x24/0x34
[   14.542510]  bus_add_driver+0x154/0x270
[   14.542514]  driver_register+0x68/0x104
[   14.542518]  usb_gadget_register_driver_owner+0x48/0xf4
[   14.542523]  gadget_dev_desc_UDC_store+0xf8/0x144
[   14.542526]  configfs_write_iter+0xf0/0x138

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Akash M &lt;akash.m5@samsung.com&gt;
Link: https://lore.kernel.org/r/20241219125221.1679-1-akash.m5@samsung.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: core: Disable LPM only for non-suspended ports</title>
<updated>2024-12-23T17:54:20Z</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kaihengf@nvidia.com</email>
</author>
<published>2024-12-06T07:48:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=59bfeaf5454b7e764288d84802577f4a99bf0819'/>
<id>urn:sha1:59bfeaf5454b7e764288d84802577f4a99bf0819</id>
<content type='text'>
There's USB error when tegra board is shutting down:
[  180.919315] usb 2-3: Failed to set U1 timeout to 0x0,error code -113
[  180.919995] usb 2-3: Failed to set U1 timeout to 0xa,error code -113
[  180.920512] usb 2-3: Failed to set U2 timeout to 0x4,error code -113
[  186.157172] tegra-xusb 3610000.usb: xHCI host controller not responding, assume dead
[  186.157858] tegra-xusb 3610000.usb: HC died; cleaning up
[  186.317280] tegra-xusb 3610000.usb: Timeout while waiting for evaluate context command

The issue is caused by disabling LPM on already suspended ports.

For USB2 LPM, the LPM is already disabled during port suspend. For USB3
LPM, port won't transit to U1/U2 when it's already suspended in U3,
hence disabling LPM is only needed for ports that are not suspended.

Cc: Wayne Chang &lt;waynec@nvidia.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Fixes: d920a2ed8620 ("usb: Disable USB3 LPM at shutdown")
Signed-off-by: Kai-Heng Feng &lt;kaihengf@nvidia.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20241206074817.89189-1-kaihengf@nvidia.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: fix reference leak in usb_new_device()</title>
<updated>2024-12-23T17:54:04Z</updated>
<author>
<name>Ma Ke</name>
<email>make_ruc2021@163.com</email>
</author>
<published>2024-12-18T07:13:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0df11fa8cee5a9cf8753d4e2672bb3667138c652'/>
<id>urn:sha1:0df11fa8cee5a9cf8753d4e2672bb3667138c652</id>
<content type='text'>
When device_add(&amp;udev-&gt;dev) succeeds and a later call fails,
usb_new_device() does not properly call device_del(). As comment of
device_add() says, 'if device_add() succeeds, you should call
device_del() when you want to get rid of it. If device_add() has not
succeeded, use only put_device() to drop the reference count'.

Found by code review.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 9f8b17e643fe ("USB: make usbdevices export their device nodes instead of using a separate class")
Signed-off-by: Ma Ke &lt;make_ruc2021@163.com&gt;
Reviewed-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Link: https://lore.kernel.org/r/20241218071346.2973980-1-make_ruc2021@163.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
