[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d43dd60-71c6-4805-738e-c69ef42138b6@gmail.com>
Date: Thu, 24 Jan 2019 11:56:23 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Marek Behun <marek.behun@....cz>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to
1000BaseX only on 6390X
On 1/24/19 11:37 AM, Marek Behun wrote:
> On Thu, 24 Jan 2019 11:27:54 -0800
> Florian Fainelli <f.fainelli@...il.com> wrote:
>
>> On 1/24/19 11:24 AM, Marek Behun wrote:
>>> On Thu, 24 Jan 2019 19:11:59 +0100
>>> Andrew Lunn <andrew@...n.ch> wrote:
>>>
>>>> On Thu, Jan 24, 2019 at 07:04:51PM +0100, Marek Behun wrote:
>>>>> What properties does the cpu port node need to contain to force
>>>>> it? phy-mode = "2500base-x"; is not enough.
>>>>
>>>> Hi Marek
>>>>
>>>> For DSA ports we have:
>>>>
>>>> phy-mode =
>>>> "rgmii-txid"; fixed-link {
>>>> speed =
>>>> <1000>; full-duplex;
>>>> };
>>>>
>>>> See dsa_port_fixed_link_register_of()
>>>>
>>>> Andrew
>>>
>>> Hi Andrew,
>>> the configuration
>>> phy-mode = "2500base-x";
>>> fixed-link {
>>> speed = <2500>;
>>> full-duplex;
>>> };
>>> does not work, because swphy does not support speed=2500 (only 10,
>>> 100 and 1000).
>>> managed = "in-band-status";
>>> does not work either.
>>>
>>> If I use speed = <1000>, then the swphy is created correctly, cmode
>>> is set correctly to 2500base-x, but speed register on the port is
>>> set to 1000, and the connection does not work.
>>>
>>> The easiest way would probably be to implement swphy to support
>>> speed 2500. But I don't know what values should the simulated PHY
>>> registers contain...
>>>
>>> The function dsa_port_fixed_link_register_of creates this phy
>>> device, adjusts the link and then calls
>>> put_device(&phydev->mdio.dev); Does this mean that the phy device
>>> is immediately destroyed?
>>
>> Yes, we should actually migrate that code over to PHYLINK, because in
>> PHYLINK the fixed links don't require creating a phy_device instance.
>> This is something that has a potential of breaking a lot of people,
>> so I have not really started doing it just yet :)
>
> phylink_create requires a net_device as first argument. what should be
> the device for cpu/dsa ports?
We would have to somehow change that assumption or introduce some low
level function for PHYLINK that are just meant to deal with the phylink
object, without the netdev, that is among other things why it has not
happened yet.
--
Florian
Powered by blists - more mailing lists