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: <CAGVrzcazh_URQw7nK3=aq-xg7sn48XVbaDdYtzzTEBB2bJUadQ@mail.gmail.com>
Date:	Fri, 27 Mar 2015 08:44:52 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Andrew Lunn <andrew@...n.ch>, netdev <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

2015-03-27 7:20 GMT-07:00 Stas Sergeev <stsp@...t.ru>:
> 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.

See my other reply, I think that by register a fixed_link_update
callback and adjusting fixed_phy_status based on the SGMII in-band
decoded data you would get all you want to work without major surgery
to the current code. If we are missing information in fixed_phy_status
to support SGMII-specific properties, maybe we could add those.
-- 
Florian
--
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/