All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Reid <preid@electromag.com.au>
To: Florian Fainelli <f.fainelli@gmail.com>, 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:32:58 +0800	[thread overview]
Message-ID: <d2da2cb2-e18d-42bb-b7c0-d7078266230e@electromag.com.au> (raw)
In-Reply-To: <e4ccd3c6-62af-adf0-cbf3-5d25ad7be89b@gmail.com>

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.

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


-- 
Regards
Phil

  parent reply	other threads:[~2019-03-19  1:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 18:28 [PATCH net-next 0/2] net: phy: Eliminate unnecessary soft Florian Fainelli
2018-09-25 18:28 ` [PATCH net-next 1/2] net: phy: Stop with excessive soft reset Florian Fainelli
2018-09-25 18:28 ` [PATCH net-next 2/2] net: phy: marvell: Avoid unnecessary " Florian Fainelli
2019-03-15  8:52   ` regression from: " Phil Reid
2019-03-15 21:58     ` Florian Fainelli
2019-03-18  2:11       ` Phil Reid
2019-03-18 17:09         ` Florian Fainelli
2019-03-18 17:15           ` Andrew Lunn
2019-03-18 17:18             ` Chris Healy
2019-03-18 17:53               ` Andrew Lunn
2019-03-19  1:32           ` Phil Reid [this message]
2019-03-19 16:53             ` Florian Fainelli
2019-03-20  1:33               ` Phil Reid
2019-03-20  2:34                 ` liweihang
2019-03-20  3:37                   ` Florian Fainelli
2019-03-20  5:16                     ` Phil Reid
2019-03-20  6:39                       ` Heiner Kallweit
2019-03-20  7:08                         ` Phil Reid
2019-03-20 12:22                     ` liweihang
2019-03-20 18:15                       ` Heiner Kallweit
2019-03-20 20:35                         ` Maxim Uvarov
2019-03-21  6:16                         ` liweihang
2019-03-21  8:07                           ` Phil Reid
2018-09-26  3:27 ` [PATCH net-next 0/2] net: phy: Eliminate unnecessary soft David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2da2cb2-e18d-42bb-b7c0-d7078266230e@electromag.com.au \
    --to=preid@electromag.com.au \
    --cc=andrew@lunn.ch \
    --cc=clemens.gruber@pqgruber.com \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dongsheng.wang@hxt-semitech.com \
    --cc=f.fainelli@gmail.com \
    --cc=harini.katakam@xilinx.com \
    --cc=hkallweit1@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.