From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: mvneta: SGMII fixed-link not so fixed
Date: Fri, 18 Sep 2015 10:30:42 -0700 [thread overview]
Message-ID: <55FC4A42.905@gmail.com> (raw)
In-Reply-To: <20150918172222.GL21084@n2100.arm.linux.org.uk>
On 18/09/15 10:22, Russell King - ARM Linux wrote:
> On Fri, Sep 18, 2015 at 07:04:09PM +0300, Stas Sergeev wrote:
>> 18.09.2015 18:43, Russell King - ARM Linux ?????:
>>> On Fri, Sep 18, 2015 at 05:45:27PM +0300, Stas Sergeev wrote:
>>>> AFAICS if it has use_inband_status==true,
>>>> then it went through of_phy_register_fixed_link(dn),
>>>
>>> That's totally incorrect. The test for setting use_inband_status in
>>> mvneta is:
>>>
>>> err = of_property_read_string(dn, "managed", &managed);
>>> pp->use_inband_status = (err == 0 &&
>>> strcmp(managed, "in-band-status") == 0);
>>
>> Arrrr! I was looking at the branch without the last
>> patch applied, so it occurred to me as
>>
>> pp->use_inband_status = (phy_mode == PHY_INTERFACE_MODE_SGMII) &&
>> fixed_phy;
>>
>> Sorry for that.
>
> Yay :)
>
>> So we seem to indeed have a nasty regression with the patch
>> that just went to stable. :( Great news.
>
> Yes.
>
>> Thanks for you time.
>>
>> I still have problems with this part though:
>>> If there's neither a MDIO PHY nor a fixed-link, then the network driver
>>> fails to initialise the device.
>>
>> I think I am looking into the right source this time, seems like
>> if we don't have both but still have managed="in-band-status", that
>> should go the fixed-link path and still work... no?
>
> If we have no fixed-link and no phy, then you're correct.
>
> However, I really don't like the idea of abusing "fixed-link" as a
> method to generate an ethtool/miitool/miidiag compatible output for
> this, but I'm willing to let that pass for the moment. :)
It is not just for that, you get all the goodies from the PHY library
without modifying your Ethernet MAC driver specifically for it:
phy_connect, adjust_link and phy_ethtool_{set,get}.
The solution that was judged being the less intrusive back then was to
provide MII-like registers, getting you all user-land to work
transparently for free, but now that I think about it, having this "MII"
translation seems a bit unnecessary, if not confusing. It may be better
to remove some of register update logic and just assign phydev members
directly...
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Stas Sergeev <stsp@list.ru>
Cc: andrew@lunn.ch, David Miller <davem@davemloft.net>,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Subject: Re: mvneta: SGMII fixed-link not so fixed
Date: Fri, 18 Sep 2015 10:30:42 -0700 [thread overview]
Message-ID: <55FC4A42.905@gmail.com> (raw)
In-Reply-To: <20150918172222.GL21084@n2100.arm.linux.org.uk>
On 18/09/15 10:22, Russell King - ARM Linux wrote:
> On Fri, Sep 18, 2015 at 07:04:09PM +0300, Stas Sergeev wrote:
>> 18.09.2015 18:43, Russell King - ARM Linux пишет:
>>> On Fri, Sep 18, 2015 at 05:45:27PM +0300, Stas Sergeev wrote:
>>>> AFAICS if it has use_inband_status==true,
>>>> then it went through of_phy_register_fixed_link(dn),
>>>
>>> That's totally incorrect. The test for setting use_inband_status in
>>> mvneta is:
>>>
>>> err = of_property_read_string(dn, "managed", &managed);
>>> pp->use_inband_status = (err == 0 &&
>>> strcmp(managed, "in-band-status") == 0);
>>
>> Arrrr! I was looking at the branch without the last
>> patch applied, so it occurred to me as
>>
>> pp->use_inband_status = (phy_mode == PHY_INTERFACE_MODE_SGMII) &&
>> fixed_phy;
>>
>> Sorry for that.
>
> Yay :)
>
>> So we seem to indeed have a nasty regression with the patch
>> that just went to stable. :( Great news.
>
> Yes.
>
>> Thanks for you time.
>>
>> I still have problems with this part though:
>>> If there's neither a MDIO PHY nor a fixed-link, then the network driver
>>> fails to initialise the device.
>>
>> I think I am looking into the right source this time, seems like
>> if we don't have both but still have managed="in-band-status", that
>> should go the fixed-link path and still work... no?
>
> If we have no fixed-link and no phy, then you're correct.
>
> However, I really don't like the idea of abusing "fixed-link" as a
> method to generate an ethtool/miitool/miidiag compatible output for
> this, but I'm willing to let that pass for the moment. :)
It is not just for that, you get all the goodies from the PHY library
without modifying your Ethernet MAC driver specifically for it:
phy_connect, adjust_link and phy_ethtool_{set,get}.
The solution that was judged being the less intrusive back then was to
provide MII-like registers, getting you all user-land to work
transparently for free, but now that I think about it, having this "MII"
translation seems a bit unnecessary, if not confusing. It may be better
to remove some of register update logic and just assign phydev members
directly...
--
Florian
next prev parent reply other threads:[~2015-09-18 17:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 10:32 mvneta: SGMII fixed-link not so fixed Russell King - ARM Linux
2015-09-14 10:32 ` Russell King - ARM Linux
2015-09-14 11:06 ` Stas Sergeev
2015-09-14 11:06 ` Stas Sergeev
2015-09-14 11:42 ` Russell King - ARM Linux
2015-09-14 11:42 ` Russell King - ARM Linux
2015-09-17 22:12 ` David Miller
2015-09-17 22:12 ` David Miller
2015-09-17 23:02 ` Florian Fainelli
2015-09-17 23:02 ` Florian Fainelli
2015-09-17 23:26 ` David Miller
2015-09-17 23:26 ` David Miller
2015-09-17 23:14 ` Russell King - ARM Linux
2015-09-17 23:14 ` Russell King - ARM Linux
2015-09-17 23:36 ` Florian Fainelli
2015-09-17 23:36 ` Florian Fainelli
2015-09-18 8:14 ` Russell King - ARM Linux
2015-09-18 8:14 ` Russell King - ARM Linux
2015-09-18 11:29 ` Stas Sergeev
2015-09-18 11:29 ` Stas Sergeev
2015-09-18 12:13 ` Russell King - ARM Linux
2015-09-18 12:13 ` Russell King - ARM Linux
2015-09-18 12:43 ` Stas Sergeev
2015-09-18 12:43 ` Stas Sergeev
2015-09-18 13:12 ` Russell King - ARM Linux
2015-09-18 13:12 ` Russell King - ARM Linux
2015-09-18 13:43 ` Stas Sergeev
2015-09-18 13:43 ` Stas Sergeev
2015-09-18 13:57 ` Russell King - ARM Linux
2015-09-18 13:57 ` Russell King - ARM Linux
2015-09-18 14:45 ` Stas Sergeev
2015-09-18 14:45 ` Stas Sergeev
2015-09-18 15:43 ` Russell King - ARM Linux
2015-09-18 15:43 ` Russell King - ARM Linux
2015-09-18 16:04 ` Stas Sergeev
2015-09-18 16:04 ` Stas Sergeev
2015-09-18 17:22 ` Russell King - ARM Linux
2015-09-18 17:22 ` Russell King - ARM Linux
2015-09-18 17:30 ` Florian Fainelli [this message]
2015-09-18 17:30 ` Florian Fainelli
2015-09-18 19:38 ` Stas Sergeev
2015-09-18 19:38 ` Stas Sergeev
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=55FC4A42.905@gmail.com \
--to=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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.