From: Stas Sergeev <stsp@list.ru>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org,
Linux kernel <linux-kernel@vger.kernel.org>,
Stas Sergeev <stsp@users.sourceforge.net>
Subject: Re: [PATCH 0/6] mvneta: SGMII-based in-band link state signaling
Date: Fri, 27 Mar 2015 17:20:32 +0300 [thread overview]
Message-ID: <55156730.5030807@list.ru> (raw)
In-Reply-To: <20150327135904.GB11975@lunn.ch>
27.03.2015 16:59, Andrew Lunn пишет:
>> But there is no MDIO, because SGMII AFAIK doesn't need MDIO.
>> SGMII has in-band status, but for some reason it seems currently
>> linux is not ready for such setup - this is what my patch addresses.
>
> Hacking the fixed-link driver feels wrong to me. You probably want to
> implement an SGMII-link driver. With some refactoring you can probably
> re-use some of the fixed-link driver code, but it should be a separate
> driver, with its own DT binding.
Well I took the path of "the least resistance" of course...
and the one that doesn't look unreasonable to me, but the separate
driver is an option too. Though it will really be just the "same
fixed-link with 3 added functions to change properties". Do we really
need 2 mostly similar drivers? Esp when one includes the functionality
of the other, and just adds a bit on top? Maybe having just one, with
all the capabilities added?
For example, maybe someone will later want the ability to alter the
properties of fixed-link with ethtool or alike? Will this also require
"just another fixed link driver"?
Having one fully-featured driver will allow us to add the "sgmii-link"
DT binding as an alias to "fixed-link" and some function like
of_phy_fixed_link_is_sgmii() that will tell us whether we need an
in-band status or not.
> But i'm no export here. So lets see what others say.
Right. If people will be negative to an addition to fixed-link driver,
I'll take a look into adding a new DT binding - something I'd really
like to avoid doing. :) More work, more code, and yet even a new config
option - this have to be justified.
next prev parent reply other threads:[~2015-03-27 14:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 13:28 [PATCH 0/6] mvneta: SGMII-based in-band link state signaling Stas Sergeev
2015-03-27 13:31 ` PATCH 1/6] fixed_phy: pass phy_device instead of net_device to link_update() function Stas Sergeev
2015-03-27 13:33 ` [PATCH 2/6] fixed_phy: add fixed_phy_unregister() Stas Sergeev
2015-03-27 13:34 ` [PATCH 1/6] fixed_phy: pass phy_device instead of net_device to link_update() function Stas Sergeev
2015-03-27 13:35 ` [PATCH 3/6] of_mdio: restructure of_phy_register_fixed_link() for further modifications Stas Sergeev
2015-03-27 13:37 ` [PATCH 4/6] of: add API for changing parameters of fixed link Stas Sergeev
[not found] ` <55155D35.1070703-cmBhpYW9OiY@public.gmane.org>
2015-03-27 15:41 ` Florian Fainelli
2015-03-27 15:41 ` Florian Fainelli
2015-03-27 16:07 ` Stas Sergeev
2015-03-27 16:21 ` Florian Fainelli
[not found] ` <CAGVrzcaLfQcTAx8OR=sE=7FLrp0gGvfX8_YfxK_CU+x26JHymw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-27 16:39 ` Stas Sergeev
2015-03-27 16:39 ` Stas Sergeev
2015-03-27 17:15 ` Florian Fainelli
2015-03-27 17:31 ` Stas Sergeev
2015-03-30 14:39 ` Stas Sergeev
2015-03-30 16:06 ` Florian Fainelli
2015-03-30 17:04 ` Stas Sergeev
2015-03-31 17:11 ` Stas Sergeev
2015-03-27 13:39 ` [PATCH 0/6] mvneta: SGMII-based in-band link state signaling Andrew Lunn
2015-03-27 13:52 ` Stas Sergeev
2015-03-27 13:59 ` Andrew Lunn
2015-03-27 14:20 ` Stas Sergeev [this message]
2015-03-27 15:44 ` Florian Fainelli
2015-03-27 13:39 ` [PATCH 5/6] mvneta: implement " Stas Sergeev
2015-07-08 16:30 ` [5/6] " Sebastien Rannou
2015-07-08 16:51 ` Stas Sergeev
2015-07-09 9:03 ` Sebastien Rannou
2015-07-09 9:19 ` Thomas Petazzoni
2015-07-09 10:11 ` Stas Sergeev
2015-03-27 13:40 ` [PATCH 6/6] mvneta: port marvell's official in-band status enabling procedure 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=55156730.5030807@list.ru \
--to=stsp@list.ru \
--cc=andrew@lunn.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stsp@users.sourceforge.net \
/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.