linux-stable.git/drivers/phy, branch linux-5.8.y

phy: marvell: comphy: Convert internal SMCC firmware return codes to errno

2020-11-01T11:45:43+00:00

commit ea17a0f153af2cd890e4ce517130dcccaa428c13 upstream.

Driver ->power_on and ->power_off callbacks leaks internal SMCC firmware
return codes to phy caller. This patch converts SMCC error codes to
standard linux errno codes. Include file linux/arm-smccc.h already provides
defines for SMCC error codes, so use them instead of custom driver defines.
Note that return value is signed 32bit, but stored in unsigned long type
with zero padding.

Tested-by: Tomasz Maciej Nowak 
Link: https://lore.kernel.org/r/20200902144344.16684-2-pali@kernel.org
Signed-off-by: Pali Rohár 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

phy: ti: am654: Fix a leak in serdes_am654_probe()

2020-10-07T06:02:50+00:00

[ Upstream commit 850280156f6421a404f2351bee07a0e7bedfd4c6 ]

If devm_phy_create() fails then we need to call of_clk_del_provider(node)
to undo the call to of_clk_add_provider().

Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC")
Signed-off-by: Dan Carpenter 
Link: https://lore.kernel.org/r/20200905124648.GA183976@mwanda
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: omap-usb2-phy: disable PHY charger detect

2020-09-23T10:59:49+00:00

[ Upstream commit ad7a7acaedcf45071c822b6c983f9c1e084041c9 ]

AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which
could cause enumeration failure with some USB hubs.  Disabling the
USB2_PHY Charger Detect function will put D+ into the normal state.

This addresses Silicon Errata:
i2075 - "USB2PHY: USB2PHY Charger Detect is Enabled by Default Without VBUS
Presence"

Signed-off-by: Roger Quadros 
Tested-by: Jan Kiszka 
Link: https://lore.kernel.org/r/20200824075127.14902-2-rogerq@ti.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: qcom-qmp: Use correct values for ipq8074 PCIe Gen2 PHY init

2020-09-17T11:55:45+00:00

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 
Signed-off-by: Selvam Sathappan Periakaruppan 
Signed-off-by: Sivaprakash Murugesan 
Link: https://lore.kernel.org/r/1596036607-11877-4-git-send-email-sivaprak@codeaurora.org
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

phy: armada-38x: fix NETA lockup when repeatedly switching speeds

2020-08-19T06:26:41+00:00

[ 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 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/E1jxtRj-0003Tz-CG@rmk-PC.armlinux.org.uk
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: renesas: rcar-gen3-usb2: move irq registration to init

2020-08-19T06:26:38+00:00

[ 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 
Reported-by: Geert Uytterhoeven 
Fixes: 9f391c574efc ("phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection")
Signed-off-by: Yoshihiro Shimoda 
Link: https://lore.kernel.org/r/1594986297-12434-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: exynos5-usbdrd: Calibrating makes sense only for USB2.0 PHY

2020-08-19T06:26:34+00:00

[ 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 
Acked-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200708133800.3336-1-m.szyprowski@samsung.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: cadence: salvo: fix wrong bit definition

2020-08-19T06:26:33+00:00

[ Upstream commit 270ff6048f45759d31a7b62d3983b084153837f5 ]

It fixes RX detect wakeup using USB3 device, otherwise, the USB3
device can't wakeup USB PHY when the PHY is in 32Khz clock.

Fixes: 50d35aa8c15f ("phy: cadence: salvo: add salvo phy driver")
Signed-off-by: Peter Chen 
Link: https://lore.kernel.org/r/20200703064600.14181-1-peter.chen@nxp.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

Merge tag 'phy-fixes-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next

2020-07-08T16:00:07+00:00

Vinod writes:

phy: fixes for 5.8

*) Fix for intel combo driver for warns or errors
*) Constify symbols for am654-serdes & j721e-wiz
*) Return value fix for rockchip driver
*) Null pointer dereference fix for sun4i-usb

* tag 'phy-fixes-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy:
  phy: sun4i-usb: fix dereference of pointer phy0 before it is null checked
  phy: rockchip: Fix return value of inno_dsidphy_probe()
  phy: ti: j721e-wiz: Constify structs
  phy: ti: am654-serdes: Constify regmap_config
  phy: intel: fix enum type mismatch warning
  phy: intel: Fix compilation error on FIELD_PREP usage

phy: sun4i-usb: fix dereference of pointer phy0 before it is null checked

2020-06-25T12:55:37+00:00

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 
Link: https://lore.kernel.org/r/20200625124428.83564-1-colin.king@canonical.com
Signed-off-by: Vinod Koul