linux-kernel - Re: [PATCH 0/6] mvneta: SGMII-based in-band link state signaling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55156730.5030807@list.ru>
Date:	Fri, 27 Mar 2015 17:20:32 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andrew Lunn <andrew@...n.ch>
CC:	netdev@...r.kernel.org,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Stas Sergeev <stsp@...rs.sourceforge.net>
Subject: Re: [PATCH 0/6] mvneta: SGMII-based in-band link state signaling

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/