<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/usb, branch v5.4.232</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>usb: typec: altmodes/displayport: Fix probe pin assign check</title>
<updated>2023-02-22T11:50:33+00:00</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2023-02-08T20:53:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b5d37d3288d6123415bbc4b430cc50606cfced1'/>
<id>9b5d37d3288d6123415bbc4b430cc50606cfced1</id>
<content type='text'>
commit 54e5c00a4eb0a4c663445b245f641bbfab142430 upstream.

While checking Pin Assignments of the port and partner during probe, we
don't take into account whether the peripheral is a plug or receptacle.

This manifests itself in a mode entry failure on certain docks and
dongles with captive cables. For instance, the Startech.com Type-C to DP
dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail
the Pin Assignment compatibility check, despite it supporting
Pin Assignment C as a UFP.

Update the check to use the correct DP Pin Assign macros that
take the peripheral's receptacle bit into account.

Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Reported-by: Diana Zigterman &lt;dzigterman@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.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>
commit 54e5c00a4eb0a4c663445b245f641bbfab142430 upstream.

While checking Pin Assignments of the port and partner during probe, we
don't take into account whether the peripheral is a plug or receptacle.

This manifests itself in a mode entry failure on certain docks and
dongles with captive cables. For instance, the Startech.com Type-C to DP
dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail
the Pin Assignment compatibility check, despite it supporting
Pin Assignment C as a UFP.

Update the check to use the correct DP Pin Assign macros that
take the peripheral's receptacle bit into account.

Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Reported-by: Diana Zigterman &lt;dzigterman@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: core: add quirk for Alcor Link AK9563 smartcard reader</title>
<updated>2023-02-22T11:50:32+00:00</updated>
<author>
<name>Mark Pearson</name>
<email>mpearson-lenovo@squebb.ca</email>
</author>
<published>2023-02-08T18:12:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d9758f7deb5a5931b0e855b6ab26bd7ad897ddd1'/>
<id>d9758f7deb5a5931b0e855b6ab26bd7ad897ddd1</id>
<content type='text'>
commit 303e724d7b1e1a0a93daf0b1ab5f7c4f53543b34 upstream.

The Alcor Link AK9563 smartcard reader used on some Lenovo platforms
doesn't work. If LPM is enabled the reader will provide an invalid
usb config descriptor. Added quirk to disable LPM.

Verified fix on Lenovo P16 G1 and T14 G3

Tested-by: Miroslav Zatko &lt;mzatko@mirexoft.com&gt;
Tested-by: Dennis Wassenberg &lt;dennis.wassenberg@secunet.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dennis Wassenberg &lt;dennis.wassenberg@secunet.com&gt;
Signed-off-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.ca
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 303e724d7b1e1a0a93daf0b1ab5f7c4f53543b34 upstream.

The Alcor Link AK9563 smartcard reader used on some Lenovo platforms
doesn't work. If LPM is enabled the reader will provide an invalid
usb config descriptor. Added quirk to disable LPM.

Verified fix on Lenovo P16 G1 and T14 G3

Tested-by: Miroslav Zatko &lt;mzatko@mirexoft.com&gt;
Tested-by: Dennis Wassenberg &lt;dennis.wassenberg@secunet.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dennis Wassenberg &lt;dennis.wassenberg@secunet.com&gt;
Signed-off-by: Mark Pearson &lt;mpearson-lenovo@squebb.ca&gt;
Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.ca
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Fix unbalanced spinlock in __ffs_ep0_queue_wait</title>
<updated>2023-02-22T11:50:26+00:00</updated>
<author>
<name>Udipto Goswami</name>
<email>quic_ugoswami@quicinc.com</email>
</author>
<published>2023-01-24T09:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5bf0010b87be18c4bf23b2f75be065b0c5264fe4'/>
<id>5bf0010b87be18c4bf23b2f75be065b0c5264fe4</id>
<content type='text'>
[ Upstream commit 921deb9da15851425ccbb6ee409dc2fd8fbdfe6b ]

__ffs_ep0_queue_wait executes holding the spinlock of &amp;ffs-&gt;ev.waitq.lock
and unlocks it after the assignments to usb_request are done.
However in the code if the request is already NULL we bail out returning
-EINVAL but never unlocked the spinlock.

Fix this by adding spin_unlock_irq &amp;ffs-&gt;ev.waitq.lock before returning.

Fixes: 6a19da111057 ("usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait")
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Link: https://lore.kernel.org/r/20230124091149.18647-1-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 921deb9da15851425ccbb6ee409dc2fd8fbdfe6b ]

__ffs_ep0_queue_wait executes holding the spinlock of &amp;ffs-&gt;ev.waitq.lock
and unlocks it after the assignments to usb_request are done.
However in the code if the request is already NULL we bail out returning
-EINVAL but never unlocked the spinlock.

Fix this by adding spin_unlock_irq &amp;ffs-&gt;ev.waitq.lock before returning.

Fixes: 6a19da111057 ("usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait")
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Link: https://lore.kernel.org/r/20230124091149.18647-1-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: dwc3: qcom: enable vbus override when in OTG dr-mode</title>
<updated>2023-02-22T11:50:26+00:00</updated>
<author>
<name>Neil Armstrong</name>
<email>neil.armstrong@linaro.org</email>
</author>
<published>2023-01-24T08:31:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db3798943ab7ae897e8205091ad12e3bb9e5ac95'/>
<id>db3798943ab7ae897e8205091ad12e3bb9e5ac95</id>
<content type='text'>
[ Upstream commit eb320f76e31dc835b9f57f04af1a2353b13bb7d8 ]

With vbus override enabled when in OTG dr_mode, Host&lt;-&gt;Peripheral
switch now works on SM8550, otherwise the DWC3 seems to be stuck
in Host mode only.

Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Reviewed-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://lore.kernel.org/r/20230123-topic-sm8550-upstream-dwc3-qcom-otg-v2-1-2d400e598463@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit eb320f76e31dc835b9f57f04af1a2353b13bb7d8 ]

With vbus override enabled when in OTG dr_mode, Host&lt;-&gt;Peripheral
switch now works on SM8550, otherwise the DWC3 seems to be stuck
in Host mode only.

Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Reviewed-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://lore.kernel.org/r/20230123-topic-sm8550-upstream-dwc3-qcom-otg-v2-1-2d400e598463@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: dwc3: dwc3-qcom: Fix typo in the dwc3 vbus override API</title>
<updated>2023-02-22T11:50:26+00:00</updated>
<author>
<name>Wesley Cheng</name>
<email>wcheng@codeaurora.org</email>
</author>
<published>2021-07-04T01:33:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fefffc7825007276196f588983208547de594026'/>
<id>fefffc7825007276196f588983208547de594026</id>
<content type='text'>
[ Upstream commit 8e6cb5d27e8246d9c986ec162d066a502d2b602b ]

There was an extra character in the dwc3_qcom_vbus_override_enable()
function.  Removed the extra character.

Signed-off-by: Wesley Cheng &lt;wcheng@codeaurora.org&gt;
Signed-off-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Link: https://lore.kernel.org/r/20210704013314.200951-2-bryan.odonoghue@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: eb320f76e31d ("usb: dwc3: qcom: enable vbus override when in OTG dr-mode")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8e6cb5d27e8246d9c986ec162d066a502d2b602b ]

There was an extra character in the dwc3_qcom_vbus_override_enable()
function.  Removed the extra character.

Signed-off-by: Wesley Cheng &lt;wcheng@codeaurora.org&gt;
Signed-off-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Link: https://lore.kernel.org/r/20210704013314.200951-2-bryan.odonoghue@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: eb320f76e31d ("usb: dwc3: qcom: enable vbus override when in OTG dr-mode")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: host: xhci-plat: add wakeup entry at sysfs</title>
<updated>2023-02-06T06:52:51+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@nxp.com</email>
</author>
<published>2020-09-18T13:17:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c24a20223dbb09eff3f8b859140d5371e02f362'/>
<id>6c24a20223dbb09eff3f8b859140d5371e02f362</id>
<content type='text'>
commit 4bb4fc0dbfa23acab9b762949b91ffd52106fe4b upstream.

With this change, there will be a wakeup entry at /sys/../power/wakeup,
and the user could use this entry to choose whether enable xhci wakeup
features (wake up system from suspend) or not.

Tested-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Reviewed-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20200918131752.16488-6-mathias.nyman@linux.intel.com
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
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 4bb4fc0dbfa23acab9b762949b91ffd52106fe4b upstream.

With this change, there will be a wakeup entry at /sys/../power/wakeup,
and the user could use this entry to choose whether enable xhci wakeup
features (wake up system from suspend) or not.

Tested-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Reviewed-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20200918131752.16488-6-mathias.nyman@linux.intel.com
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Revert "xhci: Set HCD flag to defer primary roothub registration""</title>
<updated>2023-02-06T06:52:43+00:00</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2023-01-26T14:21:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e588a5872d412d55fd458edd1fee5f86962b0898'/>
<id>e588a5872d412d55fd458edd1fee5f86962b0898</id>
<content type='text'>
This reverts commit 049849492b77aa0df7f7130f1d522f3553c4084b.

Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 049849492b77aa0df7f7130f1d522f3553c4084b.

Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Ensure ep0req is dequeued before free_request</title>
<updated>2023-02-06T06:52:39+00:00</updated>
<author>
<name>Udipto Goswami</name>
<email>quic_ugoswami@quicinc.com</email>
</author>
<published>2022-12-15T05:29:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7335ba0c0345c87aaf9b641360dc30c6d4a49555'/>
<id>7335ba0c0345c87aaf9b641360dc30c6d4a49555</id>
<content type='text'>
[ Upstream commit ce405d561b020e5a46340eb5146805a625dcacee ]

As per the documentation, function usb_ep_free_request guarantees
the request will not be queued or no longer be re-queued (or
otherwise used). However, with the current implementation it
doesn't make sure that the request in ep0 isn't reused.

Fix this by dequeuing the ep0req on functionfs_unbind before
freeing the request to align with the definition.

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Tested-by: Krishna Kurapati &lt;quic_kriskura@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221215052906.8993-3-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ce405d561b020e5a46340eb5146805a625dcacee ]

As per the documentation, function usb_ep_free_request guarantees
the request will not be queued or no longer be re-queued (or
otherwise used). However, with the current implementation it
doesn't make sure that the request in ep0 isn't reused.

Fix this by dequeuing the ep0req on functionfs_unbind before
freeing the request to align with the definition.

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Tested-by: Krishna Kurapati &lt;quic_kriskura@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221215052906.8993-3-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait</title>
<updated>2023-02-06T06:52:38+00:00</updated>
<author>
<name>Udipto Goswami</name>
<email>quic_ugoswami@quicinc.com</email>
</author>
<published>2022-12-15T05:29:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a8d40942df074f4ebcb9bd3413596d92f323b064'/>
<id>a8d40942df074f4ebcb9bd3413596d92f323b064</id>
<content type='text'>
[ Upstream commit 6a19da111057f69214b97c62fb0ac59023970850 ]

While performing fast composition switch, there is a possibility that the
process of ffs_ep0_write/ffs_ep0_read get into a race condition
due to ep0req being freed up from functionfs_unbind.

Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait
by taking a lock &amp;ffs-&gt;ev.waitq.lock. However, the functionfs_unbind isn't
bounded so it can go ahead and mark the ep0req to NULL, and since there
is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.

Fix this by making a serialized execution between the two functions using
a mutex_lock(ffs-&gt;mutex).

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Tested-by: Krishna Kurapati &lt;quic_kriskura@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221215052906.8993-2-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6a19da111057f69214b97c62fb0ac59023970850 ]

While performing fast composition switch, there is a possibility that the
process of ffs_ep0_write/ffs_ep0_read get into a race condition
due to ep0req being freed up from functionfs_unbind.

Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait
by taking a lock &amp;ffs-&gt;ev.waitq.lock. However, the functionfs_unbind isn't
bounded so it can go ahead and mark the ep0req to NULL, and since there
is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.

Fix this by making a serialized execution between the two functions using
a mutex_lock(ffs-&gt;mutex).

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Signed-off-by: Udipto Goswami &lt;quic_ugoswami@quicinc.com&gt;
Tested-by: Krishna Kurapati &lt;quic_kriskura@quicinc.com&gt;
Link: https://lore.kernel.org/r/20221215052906.8993-2-quic_ugoswami@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210</title>
<updated>2023-01-24T06:18:01+00:00</updated>
<author>
<name>Juhyung Park</name>
<email>qkrwngud825@gmail.com</email>
</author>
<published>2023-01-17T08:51:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aa1b22daa019438f267e4054f97a9f48f2caa113'/>
<id>aa1b22daa019438f267e4054f97a9f48f2caa113</id>
<content type='text'>
commit dbd24ec17b85b45f4e823d1aa5607721920f2b05 upstream.

The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
blacklists UAS for all of RTL9210 enclosures.

The RTL9210 controller was advertised with UAS since its release back in
2019 and was shipped with a lot of enclosure products with different
firmware combinations.

Blacklist UAS only for HIKSEMI MD202.

This should hopefully be replaced with more robust method than just
comparing strings.  But with limited information [1] provided thus far
(dmesg when the device is plugged in, which includes manufacturer and
product, but no lsusb -v to compare against), this is the best we can do
for now.

[1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com

Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: Hongling Zeng &lt;zenghongling@kylinos.cn&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Juhyung Park &lt;qkrwngud825@gmail.com&gt;
Acked-by: Oliver Neukum &lt;oneukum@suse.com&gt;
Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.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 dbd24ec17b85b45f4e823d1aa5607721920f2b05 upstream.

The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
blacklists UAS for all of RTL9210 enclosures.

The RTL9210 controller was advertised with UAS since its release back in
2019 and was shipped with a lot of enclosure products with different
firmware combinations.

Blacklist UAS only for HIKSEMI MD202.

This should hopefully be replaced with more robust method than just
comparing strings.  But with limited information [1] provided thus far
(dmesg when the device is plugged in, which includes manufacturer and
product, but no lsusb -v to compare against), this is the best we can do
for now.

[1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com

Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: Hongling Zeng &lt;zenghongling@kylinos.cn&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Juhyung Park &lt;qkrwngud825@gmail.com&gt;
Acked-by: Oliver Neukum &lt;oneukum@suse.com&gt;
Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
