Re: regression from: net: phy: marvell: Avoid unnecessary soft reset

From: Florian Fainelli <f.fainelli@gmail.com>
To: Phil Reid <preid@electromag.com.au>, netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	dongsheng.wang@hxt-semitech.com, cphealy@gmail.com,
	clemens.gruber@pqgruber.com, hkallweit1@gmail.com, nbd@nbd.name,
	harini.katakam@xilinx.com
Subject: Re: regression from: net: phy: marvell: Avoid unnecessary soft reset
Date: Tue, 19 Mar 2019 09:53:22 -0700	[thread overview]
Message-ID: <7338bda7-541a-ed20-0afa-f5840c8fd131@gmail.com> (raw)
In-Reply-To: <d2da2cb2-e18d-42bb-b7c0-d7078266230e@electromag.com.au>

On 3/18/19 6:32 PM, Phil Reid wrote:
> On 19/03/2019 1:09 am, Florian Fainelli wrote:
>> On 3/17/19 7:11 PM, Phil Reid wrote:
>>> On 16/03/2019 5:58 am, Florian Fainelli wrote:
>>>> On 3/15/19 1:52 AM, Phil Reid wrote:
>>>>> G'day All,
>>>>>
>>>>> I've just update from kernel 4.19 to 5.0 on a custom board that has a
>>>>> marvell
>>>>> dsa mv88e6085 and the phy on the mv88e6085 will only connect at
>>>>> 10Mb/s with
>>>>> the above mentioned patch applied.
>>>>>
>>>>> Bisecting the issue lead me to the following patch.
>>>>>
>>>>> d6ab93364734bd (net: phy: marvell: Avoid unnecessary soft reset)
>>>>>
>>>>> Revert the patch, and the associated build fix
>>>>> 4b1bd6976945417 (net: phy: marvell: Fix build.)
>>>>> restores connections to 1Gb/s.
>>>>>
>>>>> Anyone have any thoughts as to the correct fix?
>>>>
>>>> What is the PHY OUI (MII_PHYSID1/ID2) for that PHY? We may need to
>>>> add a
>>>> specific entry in drivers/net/phy/marvell.c to restore the software
>>>> reset to commit changes to the register.
>>>>
>>> G'day Florian,
>>>
>>> OUI is 0x005043
>>> Model is 101011
>>>
>>> Phy1ID: 0x0141
>>> Phy2ID: 0x0eb1
>>>
>>> The running phy driver is "Marvell 88E1540"
>>
>> Thanks, you mentioned a mv88e6085 but that chip is a 10/100 switch, did
>> you mean that the mv88e6085 compatible string is used in Device Tree to
>> designate that chip? While the 88E1540 driver is picked up, that driver
>> is originally for external PHY packages (AFAICT), so there could be some
>> switch-specific integration of this PHY that makes it behave
>> differently, having the OUI helps narrow down what might be necessary to
>> accomplish.
>>
>> FWIW, the changes were originally tested with a 88e6352.
>>
> 
> Oops yes that's the compatible string.
> Mfr Code we purchased was 88E6352-A1-TFJ2I000
> 
> The switch id registers (0x03) returns 0x3521
> 
> Odd it works ok for others.

One possible difference is that the device this was tested with has an
EEPROM which gets involved in configuring the switch during PoR (IIRC)
and that could produce different results. Do you have any switch
initialization happening in the boot loader by any chance?

> 
> Here's the relevant dmesgs (with the patch reverted)
> 
> [    1.332652] bus: 'mdio_bus': add driver mv88e6085
> [    1.368572] bus: 'mdio_bus': driver_probe_device: matched device
> stmmac-0:00 with driver mv88e6085
> [    1.368584] bus: 'mdio_bus': really_probe: probing driver mv88e6085
> with device stmmac-0:00
> [    1.368603] mv88e6085 stmmac-0:00: no pinctrl handle
> [    1.368630] mv88e6085 stmmac-0:00: GPIO lookup for consumer reset
> [    1.368638] mv88e6085 stmmac-0:00: using device tree for GPIO lookup
> [    1.368687] mv88e6085 stmmac-0:00: using lookup tables for GPIO lookup
> [    1.368696] mv88e6085 stmmac-0:00: No GPIO consumer reset found
> [    1.368835] mv88e6085 stmmac-0:00: switch 0x3520 detected: Marvell
> 88E6352, revision 1
> [    1.401845] mdio_bus stmmac-0:00: Driver mv88e6085 requests probe
> deferral
> [    2.497476] bus: 'mdio_bus': driver_probe_device: matched device
> stmmac-0:00 with driver mv88e6085
> [    2.497486] bus: 'mdio_bus': really_probe: probing driver mv88e6085
> with device stmmac-0:00
> [    2.497505] mv88e6085 stmmac-0:00: no pinctrl handle
> [    2.497536] mv88e6085 stmmac-0:00: GPIO lookup for consumer reset
> [    2.497544] mv88e6085 stmmac-0:00: using device tree for GPIO lookup
> [    2.497595] mv88e6085 stmmac-0:00: using lookup tables for GPIO lookup
> [    2.497604] mv88e6085 stmmac-0:00: No GPIO consumer reset found
> [    2.497750] mv88e6085 stmmac-0:00: switch 0x3520 detected: Marvell
> 88E6352, revision 1
> [    2.862241] mv88e6085 stmmac-0:00 lan1 (uninitialized): PHY
> [!soc!ethernet@ff702000!mdio!switch0@0!mdio:02] driver [Marvell 88E1540]
> [    2.884968] mv88e6085 stmmac-0:00 lan2 (uninitialized): PHY
> [!soc!ethernet@ff702000!mdio!switch0@0!mdio:03] driver [Marvell 88E1540]
> [    2.905318] mv88e6085 stmmac-0:00 lan3 (uninitialized): PHY
> [!soc!ethernet@ff702000!mdio!switch0@0!mdio:04] driver [Marvell 88E1540]
> [    2.917034] driver: 'mv88e6085': driver_bound: bound to device
> 'stmmac-0:00'
> [    2.917127] bus: 'mdio_bus': really_probe: bound device stmmac-0:00
> to driver mv88e6085
> [    8.293526] mv88e6085 stmmac-0:00 lan3: configuring for phy/ link mode
> [    8.305856] mv88e6085 stmmac-0:00 lan2: configuring for phy/ link mode
> [    8.325009] mv88e6085 stmmac-0:00 lan1: configuring for phy/ link mode
> [    8.342635] mv88e6085 stmmac-0:00 wifi: configuring for fixed/ link mode
> [    8.358912] mv88e6085 stmmac-0:00 wifi: Link is Up - 100Mbps/Full -
> flow control off
> [   12.034974] mv88e6085 stmmac-0:00 lan1: Link is Up - 1Gbps/Full -
> flow control rx/tx
> 
> 

-- 
Florian