From: Florian Fainelli <f.fainelli@gmail.com>
To: Stas Sergeev <stsp@list.ru>, Sebastien Rannou <mxs@sbrk.org>
Cc: Linux kernel <linux-kernel@vger.kernel.org>,
Arnaud Ebalard <arno@natisbad.org>,
Stas Sergeev <stsp@users.sourceforge.net>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Grant Likely <grant.likely@linaro.org>,
devicetree@vger.kernel.org, netdev <netdev@vger.kernel.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH 1/2] of_mdio: add new DT property 'link' for fixed-link
Date: Fri, 10 Jul 2015 11:22:52 -0700 [thread overview]
Message-ID: <55A00D7C.9090807@gmail.com> (raw)
In-Reply-To: <559FAA71.2030209@list.ru>
On 10/07/15 04:20, Stas Sergeev wrote:
> 10.07.2015 11:46, Sebastien Rannou пишет:
>> On Fri, 10 Jul 2015, Stas Sergeev wrote:
>>
>>> 10.07.2015 00:15, Florian Fainelli пишет:
>>>> Then, if the in-band status indication is not reliable (which really
>>>> should be completely understood),
>>> Agree!
>>> But this is not something I can help with.
>>> Sebastien Rannou reports the problem, please ask him whatever
>>> you see fits to get a better understanding of a problem.
>>> The fact that his HW does not generate the inband status, is
>>> _my own guess_.
>>
>> Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
>> a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
>> inband status) is connected to the switch through QSGMII, and in this context
>> we are on the media side of the PHY.
> Hmm, interesting.
> So if I parse the above correctly, you have something like 88E1340S set
> up into a mode when SGMII is used as media interface and QSGMII as system
> interface (terms are from datasheet page 5), then you connect the media
> interface to armada-xp and system interface to the switch.
>
> I wonder if it is the right thing to do.
> AFAIK you could as well set up armada-xp into QSGMII mode and connect
> that to switch. The driver would then disable the use of inband status
> and everything would be fine.
> Either way, your use-case proves that only DT can decide the use of an
> inband status.
I do not think there is any debate around the need for a property that
defines whether in-band-status is both reliable and usable, the debate
is about *where* to put it.
I still think this does not belong in the fixed-link property, but now
that you have explained a bit more in the other patch what your
understanding of "fixed-link" is, I can see the confusion.
Instead of having a link = "auto", property, how about just something
like this:
fixed-link {
speed = <1000>;
full-duplex;
use-in-band-status;
};
or event this:
fixed-link {
use-in-band-status;
};
If you parse the 'use-in-band-status' which means that it is reliable
information, then you can override whatever was defined in the DT under
the 'fixed-link' property?
--
Florian
next prev parent reply other threads:[~2015-07-10 18:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 17:34 [PATCH 0/2] enable inband link state negotiation only when explicitly requested Stas Sergeev
2015-07-09 17:38 ` [PATCH 1/2] of_mdio: add new DT property 'link' for fixed-link Stas Sergeev
2015-07-09 17:38 ` Stas Sergeev
2015-07-09 18:24 ` Florian Fainelli
2015-07-09 20:43 ` Stas Sergeev
2015-07-09 21:15 ` Florian Fainelli
2015-07-09 21:43 ` Stas Sergeev
2015-07-10 8:46 ` Sebastien Rannou
[not found] ` <alpine.LNX.2.02.1507100940530.15010-i6rsG8ix9II@public.gmane.org>
2015-07-10 11:20 ` Stas Sergeev
2015-07-10 11:20 ` Stas Sergeev
2015-07-10 18:22 ` Florian Fainelli [this message]
2015-07-09 17:41 ` [PATCH 2/2] mvneta: use inband status only when link type is "auto" Stas Sergeev
2015-07-09 18:18 ` Florian Fainelli
2015-07-09 20:26 ` Stas Sergeev
2015-07-09 21:14 ` Florian Fainelli
2015-07-09 21:31 ` Stas Sergeev
2015-07-10 12:50 ` [PATCH 0/2] enable inband link state negotiation only when explicitly requested Sebastien Rannou
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=55A00D7C.9090807@gmail.com \
--to=f.fainelli@gmail.com \
--cc=arno@natisbad.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mxs@sbrk.org \
--cc=netdev@vger.kernel.org \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=stsp@list.ru \
--cc=stsp@users.sourceforge.net \
--cc=thomas.petazzoni@free-electrons.com \
/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.