From: stsp@list.ru (Stas Sergeev)
To: linux-arm-kernel@lists.infradead.org
Subject: mvneta: SGMII fixed-link not so fixed
Date: Fri, 18 Sep 2015 22:38:55 +0300 [thread overview]
Message-ID: <55FC684F.2060808@list.ru> (raw)
In-Reply-To: <55FC4A42.905@gmail.com>
18.09.2015 20:30, Florian Fainelli ?????:
> 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}.
But you still need to modify the MAC driver, and in a bit
nasty way. Eg when you want the AN to work right, you
need to do of_phy_find_device() and feed the current AN
settings to fixed-phy manually, or, after phy_connect(), you'll
run with wrong link state for some time (and there is still
a bit of race anyway, as the link state could change between
of_phy_find_device() and phy_connect()).
So I am not sure what would the best API look like, but
my overall impression was it is currently not the one.
WARNING: multiple messages have this Message-ID (diff)
From: Stas Sergeev <stsp@list.ru>
To: Florian Fainelli <f.fainelli@gmail.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>
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 22:38:55 +0300 [thread overview]
Message-ID: <55FC684F.2060808@list.ru> (raw)
In-Reply-To: <55FC4A42.905@gmail.com>
18.09.2015 20:30, Florian Fainelli пишет:
> 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}.
But you still need to modify the MAC driver, and in a bit
nasty way. Eg when you want the AN to work right, you
need to do of_phy_find_device() and feed the current AN
settings to fixed-phy manually, or, after phy_connect(), you'll
run with wrong link state for some time (and there is still
a bit of race anyway, as the link state could change between
of_phy_find_device() and phy_connect()).
So I am not sure what would the best API look like, but
my overall impression was it is currently not the one.
next prev parent reply other threads:[~2015-09-18 19:38 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
2015-09-18 17:30 ` Florian Fainelli
2015-09-18 19:38 ` Stas Sergeev [this message]
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=55FC684F.2060808@list.ru \
--to=stsp@list.ru \
--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.