From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752911AbbC0NxE (ORCPT ); Fri, 27 Mar 2015 09:53:04 -0400 Received: from smtp38.i.mail.ru ([94.100.177.98]:37433 "EHLO smtp38.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751046AbbC0NxB (ORCPT ); Fri, 27 Mar 2015 09:53:01 -0400 Message-ID: <551560B9.1030505@list.ru> Date: Fri, 27 Mar 2015 16:52:57 +0300 From: Stas Sergeev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andrew Lunn CC: netdev@vger.kernel.org, Linux kernel , Stas Sergeev Subject: Re: [PATCH 0/6] mvneta: SGMII-based in-band link state signaling References: <55155AFC.4050800@list.ru> <20150327133907.GA11975@lunn.ch> In-Reply-To: <20150327133907.GA11975@lunn.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 27.03.2015 16:39, Andrew Lunn пишет: > On Fri, Mar 27, 2015 at 04:28:28PM +0300, Stas Sergeev wrote: >> Hello. >> >> Currently the fixed-link DT binding is pre-configured and >> cannot be changed in run-time. This means the cable unplug >> events are not being detected, and the link parameters can't >> be negotiated. > > O.K, i will ask the dumb question.... > > Isn't fixed-link supposed to be used for links which are fixed? > Why would a fixed-link change? Hi, my current understanding of fixed-link DT binding is that it is actually just an MDIO-less link, but not more fixed than that. I made a patch out of that assumption. Why I think that way is because fixed-link internally uses a fixed_phy driver - the one that actually allows a state updates and emulates MDIO on top of these. So I just exploited that already coded capability. I think any other approach will require much more work. > The use cases i've seen for this is when you are connecting the MAC to > a Switch. The link is configured to its fastest mode and then left > alone. > > Please could you give some more background information. What do you > have on the other end of this fixed link which keeps changing? > Obviously not a switch. Normal PHY, not a switch. 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. Or maybe I am missing something?