<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/phy, branch v6.15.1</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.15.1</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.15.1'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2025-05-14T11:28:43Z</updated>
<entry>
<title>phy: Fix error handling in tegra_xusb_port_init</title>
<updated>2025-05-14T11:28:43Z</updated>
<author>
<name>Ma Ke</name>
<email>make24@iscas.ac.cn</email>
</author>
<published>2025-03-03T07:27:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b2ea5f49580c0762d17d80d8083cb89bc3acf74f'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Set timing registers only once</title>
<updated>2025-05-14T11:25:09Z</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=86e70849f4b2b4597ac9f7c7931f2a363774be25'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off</title>
<updated>2025-05-14T11:25:09Z</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9ce71e85b29eb63e48e294479742e670513f03a0'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data</title>
<updated>2025-05-14T11:25:09Z</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=55a387ebb9219cbe4edfa8ba9996ccb0e7ad4932'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Move IRQ request in probe</title>
<updated>2025-05-14T11:25:09Z</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=de76809f60cc938d3580bbbd5b04b7d12af6ce3a'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind</title>
<updated>2025-05-14T11:25:09Z</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2025-05-07T12:50:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=54c4c58713aaff76c2422ff5750e557ab3b100d7'/>
<id>urn:sha1:54c4c58713aaff76c2422ff5750e557ab3b100d7</id>
<content type='text'>
It has been observed on the Renesas RZ/G3S SoC that unbinding and binding
the PHY driver leads to role autodetection failures. This issue occurs when
PHY 3 is the first initialized PHY. PHY 3 does not have an interrupt
associated with the USB2_INT_ENABLE register (as
rcar_gen3_int_enable[3] = 0). As a result, rcar_gen3_init_otg() is called
to initialize OTG without enabling PHY interrupts.

To resolve this, add rcar_gen3_is_any_otg_rphy_initialized() and call it in
role_store(), role_show(), and rcar_gen3_init_otg(). At the same time,
rcar_gen3_init_otg() is only called when initialization for a PHY with
interrupt bits is in progress. As a result, the
struct rcar_gen3_phy::otg_initialized is no longer needed.

Fixes: 549b6b55b005 ("phy: renesas: rcar-gen3-usb2: enable/disable independent irqs")
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-2-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: tegra: xusb: remove a stray unlock</title>
<updated>2025-05-14T11:21:18Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2025-04-23T13:08:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=83c178470e0bf690d34c8c08440f2421b82e881c'/>
<id>urn:sha1:83c178470e0bf690d34c8c08440f2421b82e881c</id>
<content type='text'>
We used to take a lock in tegra186_utmi_bias_pad_power_on() but now we
have moved the lock into the caller.  Unfortunately, when we moved the
lock this unlock was left behind and it results in a double unlock.
Delete it now.

Fixes: b47158fb4295 ("phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/aAjmR6To4EnvRl4G@stanley.mountain
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: phy-rockchip-samsung-hdptx: Fix PHY PLL output 50.25MHz error</title>
<updated>2025-05-14T08:55:09Z</updated>
<author>
<name>Algea Cao</name>
<email>algea.cao@rock-chips.com</email>
</author>
<published>2025-04-27T09:51:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f9475055b11c0c70979bd1667a76b2ebae638eb7'/>
<id>urn:sha1:f9475055b11c0c70979bd1667a76b2ebae638eb7</id>
<content type='text'>
When using HDMI PLL frequency division coefficient at 50.25MHz
that is calculated by rk_hdptx_phy_clk_pll_calc(), it fails to
get PHY LANE lock. Although the calculated values are within the
allowable range of PHY PLL configuration.

In order to fix the PHY LANE lock error and provide the expected
50.25MHz output, manually compute the required PHY PLL frequency
division coefficient and add it to ropll_tmds_cfg configuration
table.

Signed-off-by: Algea Cao &lt;algea.cao@rock-chips.com&gt;
Reviewed-by: Cristian Ciocaltea &lt;cristian.ciocaltea@collabora.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20250427095124.3354439-1-algea.cao@rock-chips.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failure</title>
<updated>2025-05-14T08:45:12Z</updated>
<author>
<name>Hal Feng</name>
<email>hal.feng@starfivetech.com</email>
</author>
<published>2025-04-22T10:12:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3f097adb9b6c804636bcf8d01e0e7bc037bee0d3'/>
<id>urn:sha1:3f097adb9b6c804636bcf8d01e0e7bc037bee0d3</id>
<content type='text'>
JH7110 USB 2.0 host fails to detect USB 2.0 devices occasionally. With a
long time of debugging and testing, we found that setting Rx clock gating
control signal to normal power consumption mode can solve this problem.

Signed-off-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
Link: https://lore.kernel.org/r/20250422101244.51686-1-hal.feng@starfivetech.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: rockchip-samsung-dcphy: Add missing assignment</title>
<updated>2025-04-11T11:46:22Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2025-03-21T14:36:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9cf118aafd6682793c40dde31b5f24d271da3996'/>
<id>urn:sha1:9cf118aafd6682793c40dde31b5f24d271da3996</id>
<content type='text'>
The "ret = " was accidentally dropped so the error handling doesn't work.

Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/e64265a4-9543-4728-a49f-ea910fccef7c@stanley.mountain
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
</feed>
