<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/phy, branch v6.15.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>phy: qcom-qusb2: reuse the IPQ6018 settings for IPQ5424</title>
<updated>2025-06-19T13:40:28+00:00</updated>
<author>
<name>Kathiravan Thirumoorthy</name>
<email>kathiravan.thirumoorthy@oss.qualcomm.com</email>
</author>
<published>2025-04-15T04:22:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f006ad318fa7c52c3daa978a04a8782f3dc6f2da'/>
<id>f006ad318fa7c52c3daa978a04a8782f3dc6f2da</id>
<content type='text'>
[ Upstream commit 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ]

With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add
QUSB2 support for IPQ5424"), compliance test cases especially
eye-diagram (Host High-speed Signal Quality) tests are failing.

Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware
Design Document which helps to meet all the complaince requirement test
cases.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.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 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ]

With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add
QUSB2 support for IPQ5424"), compliance test cases especially
eye-diagram (Host High-speed Signal Quality) tests are failing.

Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware
Design Document which helps to meet all the complaince requirement test
cases.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "phy: qcom-qusb2: add QUSB2 support for IPQ5424"</title>
<updated>2025-06-19T13:40:27+00:00</updated>
<author>
<name>Kathiravan Thirumoorthy</name>
<email>kathiravan.thirumoorthy@oss.qualcomm.com</email>
</author>
<published>2025-04-15T04:22:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1ec47c5f3cb2d475828754f7b751c40e465b8d69'/>
<id>1ec47c5f3cb2d475828754f7b751c40e465b8d69</id>
<content type='text'>
[ Upstream commit 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ]

With the current settings, compliance tests especially eye diagram
(Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018
settings to overcome this issue, as mentioned in the Hardware Design
Document.

So revert the change which introduced the new settings and reuse the
IPQ6018 settings in the subsequent patch.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.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 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ]

With the current settings, compliance tests especially eye diagram
(Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018
settings to overcome this issue, as mentioned in the Hardware Design
Document.

So revert the change which introduced the new settings and reuse the
IPQ6018 settings in the subsequent patch.

Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424")
Signed-off-by: Kathiravan Thirumoorthy &lt;kathiravan.thirumoorthy@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug</title>
<updated>2025-06-19T13:40:27+00:00</updated>
<author>
<name>Chenyuan Yang</name>
<email>chenyuan0y@gmail.com</email>
</author>
<published>2025-04-14T12:50:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0c33117f00c8c5363c22676931b22ae5041f7603'/>
<id>0c33117f00c8c5363c22676931b22ae5041f7603</id>
<content type='text'>
[ Upstream commit d14402a38c2d868cacb1facaf9be908ca6558e59 ]

The qmp_usb_iomap() helper function currently returns the raw result of
devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return
a NULL pointer and the caller only checks error pointers with IS_ERR(),
NULL could bypass the check and lead to an invalid dereference.

Fix the issue by checking if devm_ioremap() returns NULL. When it does,
qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM),
ensuring safe and consistent error handling.

Signed-off-by: Chenyuan Yang &lt;chenyuan0y@gmail.com&gt;
Fixes: a5d6b1ac56cb ("phy: qcom-qmp-usb: fix memleak on probe deferral")
CC: Johan Hovold &lt;johan@kernel.org&gt;
CC: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.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 d14402a38c2d868cacb1facaf9be908ca6558e59 ]

The qmp_usb_iomap() helper function currently returns the raw result of
devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return
a NULL pointer and the caller only checks error pointers with IS_ERR(),
NULL could bypass the check and lead to an invalid dereference.

Fix the issue by checking if devm_ioremap() returns NULL. When it does,
qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM),
ensuring safe and consistent error handling.

Signed-off-by: Chenyuan Yang &lt;chenyuan0y@gmail.com&gt;
Fixes: a5d6b1ac56cb ("phy: qcom-qmp-usb: fix memleak on probe deferral")
CC: Johan Hovold &lt;johan@kernel.org&gt;
CC: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: rockchip: samsung-hdptx: Do no set rk_hdptx_phy-&gt;rate in case of errors</title>
<updated>2025-06-19T13:40:26+00:00</updated>
<author>
<name>Cristian Ciocaltea</name>
<email>cristian.ciocaltea@collabora.com</email>
</author>
<published>2025-03-18T12:35:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f743e05157670994774ba906369bb818e334f1a'/>
<id>0f743e05157670994774ba906369bb818e334f1a</id>
<content type='text'>
[ Upstream commit 1f4d382769e3b38dfc498c806811dae856e40f31 ]

Ensure rk_hdptx_ropll_tmds_cmn_config() updates hdptx-&gt;rate only after
all the other operations have been successful.

Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support")
Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-4-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.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 1f4d382769e3b38dfc498c806811dae856e40f31 ]

Ensure rk_hdptx_ropll_tmds_cmn_config() updates hdptx-&gt;rate only after
all the other operations have been successful.

Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support")
Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-4-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: rockchip: samsung-hdptx: Fix clock ratio setup</title>
<updated>2025-06-19T13:40:26+00:00</updated>
<author>
<name>Cristian Ciocaltea</name>
<email>cristian.ciocaltea@collabora.com</email>
</author>
<published>2025-03-18T12:35:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=70fdc1af006b406e49ac4536b9dc73d61d2a3ee7'/>
<id>70fdc1af006b406e49ac4536b9dc73d61d2a3ee7</id>
<content type='text'>
[ Upstream commit 0422253ac1919fea8292381c85f11a9decff1bb1 ]

The switch from 1/10 to 1/40 clock ratio must happen when exceeding the
340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain,
and not before.

Therefore, use the correct comparison operator '&gt;' instead of '&gt;=' when
checking the max rate.  While at it, introduce a define for this rate
limit constant.

Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-3-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.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 0422253ac1919fea8292381c85f11a9decff1bb1 ]

The switch from 1/10 to 1/40 clock ratio must happen when exceeding the
340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain,
and not before.

Therefore, use the correct comparison operator '&gt;' instead of '&gt;=' when
checking the max rate.  While at it, introduce a define for this rate
limit constant.

Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-3-8cb1678e7663@collabora.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: Fix error handling in tegra_xusb_port_init</title>
<updated>2025-05-14T11:28:43+00:00</updated>
<author>
<name>Ma Ke</name>
<email>make24@iscas.ac.cn</email>
</author>
<published>2025-03-03T07:27:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b2ea5f49580c0762d17d80d8083cb89bc3acf74f'/>
<id>b2ea5f49580c0762d17d80d8083cb89bc3acf74f</id>
<content type='text'>
If device_add() fails, do not use device_unregister() for error
handling. device_unregister() consists two functions: device_del() and
put_device(). device_unregister() should only be called after
device_add() succeeded because device_del() undoes what device_add()
does if successful. Change device_unregister() to put_device() call
before returning from the function.

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@vger.kernel.org
Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250303072739.3874987-1-make24@iscas.ac.cn
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If device_add() fails, do not use device_unregister() for error
handling. device_unregister() consists two functions: device_del() and
put_device(). device_unregister() should only be called after
device_add() succeeded because device_del() undoes what device_add()
does if successful. Change device_unregister() to put_device() call
before returning from the function.

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@vger.kernel.org
Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250303072739.3874987-1-make24@iscas.ac.cn
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Set timing registers only once</title>
<updated>2025-05-14T11:25:09+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86e70849f4b2b4597ac9f7c7931f2a363774be25'/>
<id>86e70849f4b2b4597ac9f7c7931f2a363774be25</id>
<content type='text'>
phy-rcar-gen3-usb2 driver exports 4 PHYs. The timing registers are common
to all PHYs. There is no need to set them every time a PHY is initialized.
Set timing register only when the 1st PHY is initialized.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-6-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
phy-rcar-gen3-usb2 driver exports 4 PHYs. The timing registers are common
to all PHYs. There is no need to set them every time a PHY is initialized.
Set timing register only when the 1st PHY is initialized.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-6-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off</title>
<updated>2025-05-14T11:25:09+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9ce71e85b29eb63e48e294479742e670513f03a0'/>
<id>9ce71e85b29eb63e48e294479742e670513f03a0</id>
<content type='text'>
Assert PLL reset on PHY power off. This saves power.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-5-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Assert PLL reset on PHY power off. This saves power.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-5-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data</title>
<updated>2025-05-14T11:25:09+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=55a387ebb9219cbe4edfa8ba9996ccb0e7ad4932'/>
<id>55a387ebb9219cbe4edfa8ba9996ccb0e7ad4932</id>
<content type='text'>
The phy-rcar-gen3-usb2 driver exposes four individual PHYs that are
requested and configured by PHY users. The struct phy_ops APIs access the
same set of registers to configure all PHYs. Additionally, PHY settings can
be modified through sysfs or an IRQ handler. While some struct phy_ops APIs
are protected by a driver-wide mutex, others rely on individual
PHY-specific mutexes.

This approach can lead to various issues, including:
1/ the IRQ handler may interrupt PHY settings in progress, racing with
   hardware configuration protected by a mutex lock
2/ due to msleep(20) in rcar_gen3_init_otg(), while a configuration thread
   suspends to wait for the delay, another thread may try to configure
   another PHY (with phy_init() + phy_power_on()); re-running the
   phy_init() goes to the exact same configuration code, re-running the
   same hardware configuration on the same set of registers (and bits)
   which might impact the result of the msleep for the 1st configuring
   thread
3/ sysfs can configure the hardware (though role_store()) and it can
   still race with the phy_init()/phy_power_on() APIs calling into the
   drivers struct phy_ops

To address these issues, add a spinlock to protect hardware register access
and driver private data structures (e.g., calls to
rcar_gen3_is_any_rphy_initialized()). Checking driver-specific data remains
necessary as all PHY instances share common settings. With this change,
the existing mutex protection is removed and the cleanup.h helpers are
used.

While at it, to keep the code simpler, do not skip
regulator_enable()/regulator_disable() APIs in
rcar_gen3_phy_usb2_power_on()/rcar_gen3_phy_usb2_power_off() as the
regulators enable/disable operations are reference counted anyway.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The phy-rcar-gen3-usb2 driver exposes four individual PHYs that are
requested and configured by PHY users. The struct phy_ops APIs access the
same set of registers to configure all PHYs. Additionally, PHY settings can
be modified through sysfs or an IRQ handler. While some struct phy_ops APIs
are protected by a driver-wide mutex, others rely on individual
PHY-specific mutexes.

This approach can lead to various issues, including:
1/ the IRQ handler may interrupt PHY settings in progress, racing with
   hardware configuration protected by a mutex lock
2/ due to msleep(20) in rcar_gen3_init_otg(), while a configuration thread
   suspends to wait for the delay, another thread may try to configure
   another PHY (with phy_init() + phy_power_on()); re-running the
   phy_init() goes to the exact same configuration code, re-running the
   same hardware configuration on the same set of registers (and bits)
   which might impact the result of the msleep for the 1st configuring
   thread
3/ sysfs can configure the hardware (though role_store()) and it can
   still race with the phy_init()/phy_power_on() APIs calling into the
   drivers struct phy_ops

To address these issues, add a spinlock to protect hardware register access
and driver private data structures (e.g., calls to
rcar_gen3_is_any_rphy_initialized()). Checking driver-specific data remains
necessary as all PHY instances share common settings. With this change,
the existing mutex protection is removed and the cleanup.h helpers are
used.

While at it, to keep the code simpler, do not skip
regulator_enable()/regulator_disable() APIs in
rcar_gen3_phy_usb2_power_on()/rcar_gen3_phy_usb2_power_off() as the
regulators enable/disable operations are reference counted anyway.

Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver")
Cc: stable@vger.kernel.org
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Move IRQ request in probe</title>
<updated>2025-05-14T11:25:09+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de76809f60cc938d3580bbbd5b04b7d12af6ce3a'/>
<id>de76809f60cc938d3580bbbd5b04b7d12af6ce3a</id>
<content type='text'>
Commit 08b0ad375ca6 ("phy: renesas: rcar-gen3-usb2: move IRQ registration
to init") moved the IRQ request operation from probe to
struct phy_ops::phy_init API to avoid triggering interrupts (which lead to
register accesses) while the PHY clocks (enabled through runtime PM APIs)
are not active. If this happens, it results in a synchronous abort.

One way to reproduce this issue is by enabling CONFIG_DEBUG_SHIRQ, which
calls free_irq() on driver removal.

Move the IRQ request and free operations back to probe, and take the
runtime PM state into account in IRQ handler. This commit is preparatory
for the subsequent fixes in this series.

Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-3-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 08b0ad375ca6 ("phy: renesas: rcar-gen3-usb2: move IRQ registration
to init") moved the IRQ request operation from probe to
struct phy_ops::phy_init API to avoid triggering interrupts (which lead to
register accesses) while the PHY clocks (enabled through runtime PM APIs)
are not active. If this happens, it results in a synchronous abort.

One way to reproduce this issue is by enabling CONFIG_DEBUG_SHIRQ, which
calls free_irq() on driver removal.

Move the IRQ request and free operations back to probe, and take the
runtime PM state into account in IRQ handler. This commit is preparatory
for the subsequent fixes in this series.

Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Link: https://lore.kernel.org/r/20250507125032.565017-3-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
