<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/phy, branch v5.4.68</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-09-17T11:47:55Z</updated>
<entry>
<title>phy: qcom-qmp: Use correct values for ipq8074 PCIe Gen2 PHY init</title>
<updated>2020-09-17T11:47:55Z</updated>
<author>
<name>Sivaprakash Murugesan</name>
<email>sivaprak@codeaurora.org</email>
</author>
<published>2020-07-29T15:30:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=83db8dd32b1d00f77916dba000b02b08f74157df'/>
<id>urn:sha1:83db8dd32b1d00f77916dba000b02b08f74157df</id>
<content type='text'>
commit afd55e6d1bd35b4b36847869011447a83a81c8e0 upstream.

There were some problem in ipq8074 Gen2 PCIe phy init sequence.

1. Few register values were wrongly updated in the phy init sequence.
2. The register QSERDES_RX_SIGDET_CNTRL is a RX tuning parameter
   register which is added in serdes table causing the wrong register
   was getting updated.
3. Clocks and resets were not added in the phy init.

Fix these to make Gen2 PCIe port on ipq8074 devices to work.

Fixes: eef243d04b2b6 ("phy: qcom-qmp: Add support for IPQ8074")
Cc: stable@vger.kernel.org
Co-developed-by: Selvam Sathappan Periakaruppan &lt;speriaka@codeaurora.org&gt;
Signed-off-by: Selvam Sathappan Periakaruppan &lt;speriaka@codeaurora.org&gt;
Signed-off-by: Sivaprakash Murugesan &lt;sivaprak@codeaurora.org&gt;
Link: https://lore.kernel.org/r/1596036607-11877-4-git-send-email-sivaprak@codeaurora.org
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>phy: armada-38x: fix NETA lockup when repeatedly switching speeds</title>
<updated>2020-08-19T06:16:14Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2020-07-21T14:40:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=db2eabff57cc56658da4d5ed545c9c7cbb230db8'/>
<id>urn:sha1:db2eabff57cc56658da4d5ed545c9c7cbb230db8</id>
<content type='text'>
[ Upstream commit 1dea06cd643da38931382ebdc151efced201ffad ]

The mvneta hardware appears to lock up in various random ways when
repeatedly switching speeds between 1G and 2.5G, which involves
reprogramming the COMPHY.  It is not entirely clear why this happens,
but best guess is that reprogramming the COMPHY glitches mvneta clocks
causing the hardware to fail.  It seems that rebooting resolves the
failure, but not down/up cycling the interface alone.

Various other approaches have been tried, such as trying to cleanly
power down the COMPHY and then take it back through the power up
initialisation, but this does not seem to help.

It was finally noticed that u-boot's last step when configuring a
COMPHY for "SGMII" mode was to poke at a register described as
"GBE_CONFIGURATION_REG", which is undocumented in any external
documentation.  All that we have is the fact that u-boot sets a bit
corresponding to the "SGMII" lane at the end of COMPHY initialisation.

Experimentation shows that if we clear this bit prior to changing the
speed, and then set it afterwards, mvneta does not suffer this problem
on the SolidRun Clearfog when switching speeds between 1G and 2.5G.

This problem was found while script-testing phylink.

This fix also requires the corresponding change to DT to be effective.
See "ARM: dts: armada-38x: fix NETA lockup when repeatedly switching
speeds".

Fixes: 14dc100b4411 ("phy: armada38x: add common phy support")
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/E1jxtRj-0003Tz-CG@rmk-PC.armlinux.org.uk
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: renesas: rcar-gen3-usb2: move irq registration to init</title>
<updated>2020-08-19T06:16:13Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2020-07-17T11:44:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6112c341ba3a1b1b0c0b65bbfefea04a001f4486'/>
<id>urn:sha1:6112c341ba3a1b1b0c0b65bbfefea04a001f4486</id>
<content type='text'>
[ Upstream commit 08b0ad375ca66181faee725b1b358bcae8d592ee ]

If CONFIG_DEBUG_SHIRQ was enabled, r8a77951-salvator-xs could boot
correctly. If we appended "earlycon keep_bootcon" to the kernel
command like, we could get kernel log like below.

    SError Interrupt on CPU0, code 0xbf000002 -- SError
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-salvator-x-00505-g6c843129e6faaf01 #785
    Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
    pstate: 60400085 (nZCv daIf +PAN -UAO BTYPE=--)
    pc : rcar_gen3_phy_usb2_irq+0x14/0x54
    lr : free_irq+0xf4/0x27c

This means free_irq() calls the interrupt handler while PM runtime
is not getting if DEBUG_SHIRQ is enabled and rcar_gen3_phy_usb2_probe()
failed. To fix the issue, move the irq registration place to
rcar_gen3_phy_usb2_init() which is ready to handle the interrupts.

Note that after the commit 549b6b55b005 ("phy: renesas: rcar-gen3-usb2:
enable/disable independent irqs") which is merged into v5.2, since this
driver creates multiple phy instances, needs to check whether one of
phy instances is initialized. However, if we backport this patch to v5.1
or less, we don't need to check it because such kernel have single
phy instance.

Reported-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reported-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Fixes: 9f391c574efc ("phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Link: https://lore.kernel.org/r/1594986297-12434-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: exynos5-usbdrd: Calibrating makes sense only for USB2.0 PHY</title>
<updated>2020-08-19T06:16:11Z</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2020-07-08T13:38:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8ffa0cf2b662b0e575f77b8fee4c5e164cf19ea9'/>
<id>urn:sha1:8ffa0cf2b662b0e575f77b8fee4c5e164cf19ea9</id>
<content type='text'>
[ Upstream commit dcbabfeb17c3c2fdb6bc92a3031ecd37df1834a8 ]

PHY calibration is needed only for USB2.0 (UTMI) PHY, so skip calling
calibration code when phy_calibrate() is called for USB3.0 (PIPE3) PHY.

Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800")
Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Acked-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Link: https://lore.kernel.org/r/20200708133800.3336-1-m.szyprowski@samsung.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: sun4i-usb: fix dereference of pointer phy0 before it is null checked</title>
<updated>2020-07-22T07:33:01Z</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2020-06-25T12:44:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1d08f59081e59cadbf9189faa2aa6ff3c71e4ec1'/>
<id>urn:sha1:1d08f59081e59cadbf9189faa2aa6ff3c71e4ec1</id>
<content type='text'>
[ Upstream commit 38b1927e5bf9bcad4a2e33189ef1c5569f9599ba ]

Currently pointer phy0 is being dereferenced via the assignment of
phy on the call to phy_get_drvdata before phy0 is null checked, this
can lead to a null pointer dereference. Fix this by performing the
null check on phy0 before the call to phy_get_drvdata. Also replace
the phy0 == NULL check with the more usual !phy0 idiom.

Addresses-Coverity: ("Dereference before null check")
Fixes: e6f32efb1b12 ("phy: sun4i-usb: Make sure to disable PHY0 passby for peripheral mode")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Link: https://lore.kernel.org/r/20200625124428.83564-1-colin.king@canonical.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers: phy: sr-usb: do not use internal fsm for USB2 phy init</title>
<updated>2020-06-24T15:50:28Z</updated>
<author>
<name>Bharat Gooty</name>
<email>bharat.gooty@broadcom.com</email>
</author>
<published>2020-05-13T17:39:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8f4372f4724d06d054f3a7e5d011741bef79d5f6'/>
<id>urn:sha1:8f4372f4724d06d054f3a7e5d011741bef79d5f6</id>
<content type='text'>
[ Upstream commit 6f0577d1411337a0d97d545abe4a784e9e611516 ]

During different reboot cycles, USB PHY PLL may not always lock
during initialization and therefore can cause USB to be not usable.

Hence do not use internal FSM programming sequence for the USB
PHY initialization.

Fixes: 4dcddbb38b64 ("phy: sr-usb: Add Stingray USB PHY driver")
Signed-off-by: Bharat Gooty &lt;bharat.gooty@broadcom.com&gt;
Signed-off-by: Rayagonda Kokatanur &lt;rayagonda.kokatanur@broadcom.com&gt;
Link: https://lore.kernel.org/r/20200513173947.10919-1-rayagonda.kokatanur@broadcom.com
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: uniphier-usb3ss: Add Pro5 support</title>
<updated>2020-04-23T08:36:33Z</updated>
<author>
<name>Kunihiko Hayashi</name>
<email>hayashi.kunihiko@socionext.com</email>
</author>
<published>2020-01-30T06:52:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=81b41f5ecc966a10b46e6e53f5a7c0c10c059cca'/>
<id>urn:sha1:81b41f5ecc966a10b46e6e53f5a7c0c10c059cca</id>
<content type='text'>
[ Upstream commit 9376fa634afc207a3ce99e0957e04948c34d6510 ]

Pro5 SoC has same scheme of USB3 ss-phy as Pro4, so the data for Pro5 is
equivalent to Pro4.

Signed-off-by: Kunihiko Hayashi &lt;hayashi.kunihiko@socionext.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: ti: gmii-sel: do not fail in case of gmii</title>
<updated>2020-03-25T07:25:42Z</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2020-02-14T19:08:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5f657e5303d3ec65cc6f605d578fb22fcb847c44'/>
<id>urn:sha1:5f657e5303d3ec65cc6f605d578fb22fcb847c44</id>
<content type='text'>
[ Upstream commit 58aa7729310db04ffcc022c98002dd8fcb486c58 ]

The "gmii" PHY interface mode is supported on TI AM335x/437x/5xx SoCs, so
don't fail if it's selected.

Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: ti: gmii-sel: fix set of copy-paste errors</title>
<updated>2020-03-25T07:25:42Z</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2020-02-14T19:08:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ee1245396b6e90f1b4185f3155da715e5a8e9324'/>
<id>urn:sha1:ee1245396b6e90f1b4185f3155da715e5a8e9324</id>
<content type='text'>
[ Upstream commit eefed634eb61e4094b9fb8183cb8d43b26838517 ]

- under PHY_INTERFACE_MODE_MII the 'mode' func parameter is assigned
instead of 'gmii_sel_mode' and it's working only because the default value
'gmii_sel_mode' is set to 0.

- console outputs use 'rgmii_id' and 'mode' values to print PHY mode
instead of using 'submode' value which is representing PHY interface mode
now.

This patch fixes above two cases.

Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: mapphone-mdm6600: Fix write timeouts with shorter GPIO toggle interval</title>
<updated>2020-03-12T12:00:27Z</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2020-02-04T15:36:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4115c053a35e751d9889360e318ce793798d7e44'/>
<id>urn:sha1:4115c053a35e751d9889360e318ce793798d7e44</id>
<content type='text'>
commit 46b7edf1c7b7c91004c4db2c355cbd033f2385f9 upstream.

I've noticed that when writing data to the modem the writes can time out
at some point eventually. Looks like kicking the modem idle GPIO every
600 ms instead of once a second fixes the issue. Note that this rate is
different from our runtime PM autosuspend rate MDM6600_MODEM_IDLE_DELAY_MS
that we still want to keep at 1 second, so let's add a separate define for
PHY_MDM6600_IDLE_KICK_MS.

Fixes: f7f50b2a7b05 ("phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend")
Cc: Marcel Partap &lt;mpartap@gmx.net&gt;
Cc: Merlijn Wajer &lt;merlijn@wizzup.org&gt;
Cc: Michael Scott &lt;hashcode0f@gmail.com&gt;
Cc: NeKit &lt;nekit1000@gmail.com&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Sebastian Reichel &lt;sre@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
