linux-stable.git/drivers/phy/marvell, branch linux-5.4.y

phy: marvell: ARMADA375_USBCLUSTER_PHY should not default to y, unconditionally

2021-05-14T07:44:19+00:00

[ Upstream commit 6cb17707aad869de163d7bf42c253caf501be4e2 ]

Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, restrict the automatic enabling of ARMADA375_USBCLUSTER_PHY
to MACH_ARMADA_375, and ask the user in case of compile-testing.

Fixes: eee47538ec1f2619 ("phy: add support for USB cluster on the Armada 375 SoC")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20210208150252.424706-1-geert+renesas@glider.be
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

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

2020-11-01T11:01:07+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: armada-38x: fix NETA lockup when repeatedly switching speeds

2020-08-19T06:16:14+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: marvell: phy-mvebu-cp110-comphy: rename instances of DLT

2019-08-27T06:07:09+00:00

The documentation for Marvell's cp110 phy refers to these
registers/register regions as DTL control, DTL frequency loop enable,
etc. This patch aligns the relevant code for these accordingly.

Signed-off-by: Matt Pelland 
Signed-off-by: Kishon Vijay Abraham I

phy: marvell: phy-mvebu-cp110-comphy: implement RXAUI support

2019-08-27T06:07:09+00:00

Marvell's cp110 phy supports RXAUI on lanes 2, 3, 4, and 5 when
connected to port zero. When used in this mode, lanes operate in pairs
of two (2 and 3, 4 and 5).

Signed-off-by: Matt Pelland 
Signed-off-by: Kishon Vijay Abraham I

phy: mvebu-cp110-comphy: Update comment about powering off all lanes at boot

2019-08-27T06:07:09+00:00

Now that all COMPHY modes are supported by the driver, update the
comment stating that mvebu_comphy_power_off() should be called for
each lane. This is still wrong because for compatibility reasons, it
might break users running an old firmware (the driver only uses SMC
calls for SATA, USB and PCIe configuration, there is no code in Linux
to fallback on in these cases.

Signed-off-by: Miquel Raynal 
Signed-off-by: Kishon Vijay Abraham I

phy: mvebu-cp110-comphy: Add PCIe support

2019-08-27T06:07:09+00:00

Add PCIe support by filling the COMPHY modes table.

Also add a new macro to generate the right value for the firmware
depending on the width (PCI x1, x2, x4, etc). The width will be passed
by the core as the "submode" argument of the ->set_mode() callback. If
this argument is zero, default to x1 mode.

Signed-off-by: Grzegorz Jaszczyk 
[miquel.raynal@bootlin.com: adapt the content to the mainline driver]
Signed-off-by: Miquel Raynal 
Signed-off-by: Kishon Vijay Abraham I

phy: mvebu-cp110-comphy: Cosmetic change in a helper

2019-08-27T06:07:09+00:00

Before adding more logic, simplify a bit the writing of the
mvebu_comphy_get_mode() helper by using a pointer instead of
referencing a configuration with the entire table name.

Signed-off-by: Miquel Raynal 
Signed-off-by: Kishon Vijay Abraham I

phy: mvebu-cp110-comphy: Add SATA support

2019-08-27T06:07:09+00:00

Add the corresponding entries in the COMPHY modes table.

SATA support does not need any additional care.

Signed-off-by: Grzegorz Jaszczyk 
[miquel.raynal@bootlin.com: adapt the content to the mainline driver]
Signed-off-by: Miquel Raynal 
Signed-off-by: Kishon Vijay Abraham I

phy: mvebu-cp110-comphy: Add USB3 host/device support

2019-08-27T06:07:09+00:00

Add USB3 host/device support by adding the right entries in the COMPHY
modes table. A new macro is created to instantiate a "generic" mode
ie. not an Ethernet one. This macro will be re-used when adding SATA
support.

Signed-off-by: Grzegorz Jaszczyk 
[miquel.raynal@bootlin.com: adapt the content to the mainline driver]
Signed-off-by: Miquel Raynal 
Signed-off-by: Kishon Vijay Abraham I