From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932181AbbC0Pph (ORCPT ); Fri, 27 Mar 2015 11:45:37 -0400 Received: from mail-ob0-f178.google.com ([209.85.214.178]:34245 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753363AbbC0Ppd convert rfc822-to-8bit (ORCPT ); Fri, 27 Mar 2015 11:45:33 -0400 MIME-Version: 1.0 In-Reply-To: <55156730.5030807@list.ru> References: <55155AFC.4050800@list.ru> <20150327133907.GA11975@lunn.ch> <551560B9.1030505@list.ru> <20150327135904.GB11975@lunn.ch> <55156730.5030807@list.ru> From: Florian Fainelli Date: Fri, 27 Mar 2015 08:44:52 -0700 Message-ID: Subject: Re: [PATCH 0/6] mvneta: SGMII-based in-band link state signaling To: Stas Sergeev Cc: Andrew Lunn , netdev , Linux kernel , Stas Sergeev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2015-03-27 7:20 GMT-07:00 Stas Sergeev : > 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