<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/usb, branch v6.2-rc5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'usb-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb</title>
<updated>2023-01-21T19:10:03+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-01-21T19:10:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e67da28898e9e219176412f2fd2f415dece474ab'/>
<id>e67da28898e9e219176412f2fd2f415dece474ab</id>
<content type='text'>
Pull USB / Thunderbolt fixes from Greg KH:
 "Here are a number of small USB and Thunderbolt driver fixes and new
  device id changes for 6.2-rc5. Included in here are:

   - thunderbolt bugfixes for reported problems

   - new usb-serial driver ids added

   - onboard_hub usb driver fixes for much-reported problems

   - xhci bugfixes

   - typec bugfixes

   - ehci-fsl driver module alias fix

   - iowarrior header size fix

   - usb gadget driver fixes

  All of these, except for the iowarrior fix, have been in linux-next
  with no reported issues. The iowarrior fix passed the 0-day testing
  and is a one digit change based on a reported problem in the driver
  (which was written to a spec, not the real device that is now
  available)"

* tag 'usb-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (40 commits)
  USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
  usb: host: ehci-fsl: Fix module alias
  usb: dwc3: fix extcon dependency
  usb: core: hub: disable autosuspend for TI TUSB8041
  USB: fix misleading usb_set_intfdata() kernel doc
  usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
  USB: gadget: Add ID numbers to configfs-gadget driver names
  usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail
  usb: gadget: g_webcam: Send color matching descriptor per frame
  usb: typec: altmodes/displayport: Use proper macro for pin assignment check
  usb: typec: altmodes/displayport: Fix pin assignment calculation
  usb: typec: altmodes/displayport: Add pin assignment helper
  usb: gadget: f_fs: Ensure ep0req is dequeued before free_request
  usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
  usb: misc: onboard_hub: Move 'attach' work to the driver
  usb: misc: onboard_hub: Invert driver registration order
  usb: ucsi: Ensure connector delayed work items are flushed
  usb: musb: fix error return code in omap2430_probe()
  usb: chipidea: core: fix possible constant 0 if use IS_ERR(ci-&gt;role_switch)
  xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull USB / Thunderbolt fixes from Greg KH:
 "Here are a number of small USB and Thunderbolt driver fixes and new
  device id changes for 6.2-rc5. Included in here are:

   - thunderbolt bugfixes for reported problems

   - new usb-serial driver ids added

   - onboard_hub usb driver fixes for much-reported problems

   - xhci bugfixes

   - typec bugfixes

   - ehci-fsl driver module alias fix

   - iowarrior header size fix

   - usb gadget driver fixes

  All of these, except for the iowarrior fix, have been in linux-next
  with no reported issues. The iowarrior fix passed the 0-day testing
  and is a one digit change based on a reported problem in the driver
  (which was written to a spec, not the real device that is now
  available)"

* tag 'usb-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (40 commits)
  USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100
  usb: host: ehci-fsl: Fix module alias
  usb: dwc3: fix extcon dependency
  usb: core: hub: disable autosuspend for TI TUSB8041
  USB: fix misleading usb_set_intfdata() kernel doc
  usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
  USB: gadget: Add ID numbers to configfs-gadget driver names
  usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail
  usb: gadget: g_webcam: Send color matching descriptor per frame
  usb: typec: altmodes/displayport: Use proper macro for pin assignment check
  usb: typec: altmodes/displayport: Fix pin assignment calculation
  usb: typec: altmodes/displayport: Add pin assignment helper
  usb: gadget: f_fs: Ensure ep0req is dequeued before free_request
  usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
  usb: misc: onboard_hub: Move 'attach' work to the driver
  usb: misc: onboard_hub: Invert driver registration order
  usb: ucsi: Ensure connector delayed work items are flushed
  usb: musb: fix error return code in omap2430_probe()
  usb: chipidea: core: fix possible constant 0 if use IS_ERR(ci-&gt;role_switch)
  xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100</title>
<updated>2023-01-20T14:06:23+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-01-20T13:53:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=14ff7460bb58662d86aa50298943cc7d25532e28'/>
<id>14ff7460bb58662d86aa50298943cc7d25532e28</id>
<content type='text'>
The USB_DEVICE_ID_CODEMERCS_IOW100 header size was incorrect, it should
be 12, not 13.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 17a82716587e ("USB: iowarrior: fix up report size handling for some devices")
Reported-by: Christoph Jung &lt;jung@codemercs.com&gt;
Link: https://lore.kernel.org/r/20230120135330.3842518-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The USB_DEVICE_ID_CODEMERCS_IOW100 header size was incorrect, it should
be 12, not 13.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 17a82716587e ("USB: iowarrior: fix up report size handling for some devices")
Reported-by: Christoph Jung &lt;jung@codemercs.com&gt;
Link: https://lore.kernel.org/r/20230120135330.3842518-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: host: ehci-fsl: Fix module alias</title>
<updated>2023-01-20T13:45:12+00:00</updated>
<author>
<name>Alexander Stein</name>
<email>alexander.stein@ew.tq-group.com</email>
</author>
<published>2023-01-20T12:27:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c'/>
<id>5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c</id>
<content type='text'>
Commit ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent
driver module") changed DRV_NAME which was used for MODULE_ALIAS as well.
Starting from this the module alias didn't match the platform device
name created in fsl-mph-dr-of.c
Change DRV_NAME to match the driver name for host mode in fsl-mph-dr-of.
This is needed for module autoloading on ls1021a.

Fixes: ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent driver module")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Alexander Stein &lt;alexander.stein@ew.tq-group.com&gt;
Link: https://lore.kernel.org/r/20230120122714.3848784-1-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent
driver module") changed DRV_NAME which was used for MODULE_ALIAS as well.
Starting from this the module alias didn't match the platform device
name created in fsl-mph-dr-of.c
Change DRV_NAME to match the driver name for host mode in fsl-mph-dr-of.
This is needed for module autoloading on ls1021a.

Fixes: ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent driver module")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Alexander Stein &lt;alexander.stein@ew.tq-group.com&gt;
Link: https://lore.kernel.org/r/20230120122714.3848784-1-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'usb-serial-6.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus</title>
<updated>2023-01-19T19:03:14+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-01-19T19:03:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dcbf1742ed10ede31b2e68c1412503db9fc6cfaf'/>
<id>dcbf1742ed10ede31b2e68c1412503db9fc6cfaf</id>
<content type='text'>
Johan writes:
  "USB-serial fixes for 6.2-rc5

   Here are some new device ids, mostly for Quectel modems.

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

* tag 'usb-serial-6.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: option: add Quectel EM05CN modem
  USB: serial: option: add Quectel EM05CN (SG) modem
  USB: serial: cp210x: add SCALANCE LPE-9000 device id
  USB: serial: option: add Quectel EC200U modem
  USB: serial: option: add Quectel EM05-G (RS) modem
  USB: serial: option: add Quectel EM05-G (GR) modem
  USB: serial: option: add Quectel EM05-G (CS) modem
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Johan writes:
  "USB-serial fixes for 6.2-rc5

   Here are some new device ids, mostly for Quectel modems.

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

* tag 'usb-serial-6.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: option: add Quectel EM05CN modem
  USB: serial: option: add Quectel EM05CN (SG) modem
  USB: serial: cp210x: add SCALANCE LPE-9000 device id
  USB: serial: option: add Quectel EC200U modem
  USB: serial: option: add Quectel EM05-G (RS) modem
  USB: serial: option: add Quectel EM05-G (GR) modem
  USB: serial: option: add Quectel EM05-G (CS) modem
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: dwc3: fix extcon dependency</title>
<updated>2023-01-19T13:19:49+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2023-01-18T09:01:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7d80dbd708c18c683dd34f79b600a05307707ce8'/>
<id>7d80dbd708c18c683dd34f79b600a05307707ce8</id>
<content type='text'>
The dwc3 core support now links against the extcon subsystem,
so it cannot be built-in when extcon is a loadable module:

arm-linux-gnueabi-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_extcon':
core.c:(.text+0x572): undefined reference to `extcon_get_edev_by_phandle'
arm-linux-gnueabi-ld: core.c:(.text+0x596): undefined reference to `extcon_get_extcon_dev'
arm-linux-gnueabi-ld: core.c:(.text+0x5ea): undefined reference to `extcon_find_edev_by_node'

There was already a Kconfig dependency in the dual-role support,
but this is now needed for the entire dwc3 driver.

It is still possible to build dwc3 without extcon, but this
prevents it from being set to built-in when extcon is a loadable
module.

Fixes: d182c2e1bc92 ("usb: dwc3: Don't switch OTG -&gt; peripheral if extcon is present")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Thinh Nguyen &lt;Thinh.Nguyen@synopsys.com&gt;
Link: https://lore.kernel.org/r/20230118090147.2126563-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The dwc3 core support now links against the extcon subsystem,
so it cannot be built-in when extcon is a loadable module:

arm-linux-gnueabi-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_extcon':
core.c:(.text+0x572): undefined reference to `extcon_get_edev_by_phandle'
arm-linux-gnueabi-ld: core.c:(.text+0x596): undefined reference to `extcon_get_extcon_dev'
arm-linux-gnueabi-ld: core.c:(.text+0x5ea): undefined reference to `extcon_find_edev_by_node'

There was already a Kconfig dependency in the dual-role support,
but this is now needed for the entire dwc3 driver.

It is still possible to build dwc3 without extcon, but this
prevents it from being set to built-in when extcon is a loadable
module.

Fixes: d182c2e1bc92 ("usb: dwc3: Don't switch OTG -&gt; peripheral if extcon is present")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Thinh Nguyen &lt;Thinh.Nguyen@synopsys.com&gt;
Link: https://lore.kernel.org/r/20230118090147.2126563-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: core: hub: disable autosuspend for TI TUSB8041</title>
<updated>2023-01-17T16:40:56+00:00</updated>
<author>
<name>Flavio Suligoi</name>
<email>f.suligoi@asem.it</email>
</author>
<published>2022-12-19T12:47:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7171b0e261b17de96490adf053b8bb4b00061bcf'/>
<id>7171b0e261b17de96490adf053b8bb4b00061bcf</id>
<content type='text'>
The Texas Instruments TUSB8041 has an autosuspend problem at high
temperature.

If there is not USB traffic, after a couple of ms, the device enters in
autosuspend mode. In this condition the external clock stops working, to
save energy. When the USB activity turns on, ther hub exits the
autosuspend state, the clock starts running again and all works fine.

At ambient temperature all works correctly, but at high temperature,
when the USB activity turns on, the external clock doesn't restart and
the hub disappears from the USB bus.

Disabling the autosuspend mode for this hub solves the issue.

Signed-off-by: Flavio Suligoi &lt;f.suligoi@asem.it&gt;
Cc: stable &lt;stable@kernel.org&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Texas Instruments TUSB8041 has an autosuspend problem at high
temperature.

If there is not USB traffic, after a couple of ms, the device enters in
autosuspend mode. In this condition the external clock stops working, to
save energy. When the USB activity turns on, ther hub exits the
autosuspend state, the clock starts running again and all works fine.

At ambient temperature all works correctly, but at high temperature,
when the USB activity turns on, the external clock doesn't restart and
the hub disappears from the USB bus.

Disabling the autosuspend mode for this hub solves the issue.

Signed-off-by: Flavio Suligoi &lt;f.suligoi@asem.it&gt;
Cc: stable &lt;stable@kernel.org&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()</title>
<updated>2023-01-17T16:10:34+00:00</updated>
<author>
<name>Maciej Żenczykowski</name>
<email>maze@google.com</email>
</author>
<published>2023-01-17T13:18:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c6ec929595c7443250b2a4faea988c62019d5cd2'/>
<id>c6ec929595c7443250b2a4faea988c62019d5cd2</id>
<content type='text'>
In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is:
  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

  // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]

  // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]

  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev-&gt;gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]

  // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]

  // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]

which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:

  event-&gt;wLength = cpu_to_le16(8);
  req-&gt;length = NCM_STATUS_BYTECOUNT;

  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req-&gt;buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));

My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev-&gt;gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)-&gt;max_speed
and hits a panic.

AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)

It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...

Cc: Felipe Balbi &lt;balbi@kernel.org&gt;
Cc: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Cc: Carlos Llamas &lt;cmllamas@google.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Maciej Żenczykowski &lt;maze@google.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is:
  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

  // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]

  // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]

  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev-&gt;gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]

  // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]

  // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]

which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:

  event-&gt;wLength = cpu_to_le16(8);
  req-&gt;length = NCM_STATUS_BYTECOUNT;

  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req-&gt;buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));

My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev-&gt;gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)-&gt;max_speed
and hits a panic.

AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)

It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...

Cc: Felipe Balbi &lt;balbi@kernel.org&gt;
Cc: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Cc: Carlos Llamas &lt;cmllamas@google.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Maciej Żenczykowski &lt;maze@google.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: gadget: Add ID numbers to configfs-gadget driver names</title>
<updated>2023-01-17T16:10:00+00:00</updated>
<author>
<name>Chanh Nguyen</name>
<email>chanh@os.amperecomputing.com</email>
</author>
<published>2023-01-11T06:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7c07553807c5125c89de242d35c10c206fd8e6bb'/>
<id>7c07553807c5125c89de242d35c10c206fd8e6bb</id>
<content type='text'>
It is unable to use configfs to attach more than one gadget. When
attaching the second gadget, it always fails and the kernel message
prints out:

Error: Driver 'configfs-gadget' is already registered, aborting...
UDC core: g1: driver registration failed: -16

This commit fixes the problem by using the gadget name as a suffix
to each configfs_gadget's driver name, thus making the names
distinct.

Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Chanh Nguyen &lt;chanh@os.amperecomputing.com&gt;
Reviewed-by: Andrzej Pietrasiewicz &lt;andrzej.p@collabora.com&gt;
Tested-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Frank Li &lt;frank.li@nxp.com&gt;
Link: https://lore.kernel.org/r/20230111065105.29205-1-chanh@os.amperecomputing.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is unable to use configfs to attach more than one gadget. When
attaching the second gadget, it always fails and the kernel message
prints out:

Error: Driver 'configfs-gadget' is already registered, aborting...
UDC core: g1: driver registration failed: -16

This commit fixes the problem by using the gadget name as a suffix
to each configfs_gadget's driver name, thus making the names
distinct.

Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Chanh Nguyen &lt;chanh@os.amperecomputing.com&gt;
Reviewed-by: Andrzej Pietrasiewicz &lt;andrzej.p@collabora.com&gt;
Tested-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Frank Li &lt;frank.li@nxp.com&gt;
Link: https://lore.kernel.org/r/20230111065105.29205-1-chanh@os.amperecomputing.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail</title>
<updated>2023-01-17T16:09:27+00:00</updated>
<author>
<name>ChiYuan Huang</name>
<email>cy_huang@richtek.com</email>
</author>
<published>2023-01-09T07:19:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=36f78477ac2c89e9a2eed4a31404a291a3450b5d'/>
<id>36f78477ac2c89e9a2eed4a31404a291a3450b5d</id>
<content type='text'>
There's the altmode re-registeration issue after data role
swap (DR_SWAP).

Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
can initiate the VDM command to get partner identity information.

For a USBPD 3.0 UFP device, it may already get the identity information
from its port partner before DR_SWAP. If DR_SWAP send or receive at the
mean time, 'send_discover' flag will be raised again. It causes discover
identify action restart while entering ready state. And after all
discover actions are done, the 'tcpm_register_altmodes' will be called.
If old altmode is not unregistered, this sysfs create fail can be found.

In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
For UFP, the original altmodes keep registered.

This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
must be called whatever the current data role is.

Reviewed-by: Macpaul Lin &lt;macpaul.lin@mediatek.com&gt;
Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together")
Reported-by: TommyYl Chen &lt;tommyyl.chen@mediatek.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/1673248790-15794-1-git-send-email-cy_huang@richtek.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's the altmode re-registeration issue after data role
swap (DR_SWAP).

Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
can initiate the VDM command to get partner identity information.

For a USBPD 3.0 UFP device, it may already get the identity information
from its port partner before DR_SWAP. If DR_SWAP send or receive at the
mean time, 'send_discover' flag will be raised again. It causes discover
identify action restart while entering ready state. And after all
discover actions are done, the 'tcpm_register_altmodes' will be called.
If old altmode is not unregistered, this sysfs create fail can be found.

In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
For UFP, the original altmodes keep registered.

This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
must be called whatever the current data role is.

Reviewed-by: Macpaul Lin &lt;macpaul.lin@mediatek.com&gt;
Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together")
Reported-by: TommyYl Chen &lt;tommyyl.chen@mediatek.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/1673248790-15794-1-git-send-email-cy_huang@richtek.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: g_webcam: Send color matching descriptor per frame</title>
<updated>2023-01-17T16:08:04+00:00</updated>
<author>
<name>Daniel Scally</name>
<email>dan.scally@ideasonboard.com</email>
</author>
<published>2022-12-16T16:05:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e95765e97d9cb93258a4840440d410fa6ff7e819'/>
<id>e95765e97d9cb93258a4840440d410fa6ff7e819</id>
<content type='text'>
Currently the color matching descriptor is only sent across the wire
a single time, following the descriptors for each format and frame.
According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching
Descriptors"):

"Only one instance is allowed for a given format and if present,
the Color Matching descriptor shall be placed following the Video
and Still Image Frame descriptors for that format".

Add another reference to the color matching descriptor after the
yuyv frames so that it's correctly transmitted for that format
too.

Fixes: a9914127e834 ("USB gadget: Webcam device")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Daniel Scally &lt;dan.scally@ideasonboard.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Kieran Bingham &lt;kieran.bingham@ideasonboard.com&gt;
Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the color matching descriptor is only sent across the wire
a single time, following the descriptors for each format and frame.
According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching
Descriptors"):

"Only one instance is allowed for a given format and if present,
the Color Matching descriptor shall be placed following the Video
and Still Image Frame descriptors for that format".

Add another reference to the color matching descriptor after the
yuyv frames so that it's correctly transmitted for that format
too.

Fixes: a9914127e834 ("USB gadget: Webcam device")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Daniel Scally &lt;dan.scally@ideasonboard.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Kieran Bingham &lt;kieran.bingham@ideasonboard.com&gt;
Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
