From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01D0DC43381 for ; Sat, 2 Mar 2019 21:04:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB35F20836 for ; Sat, 2 Mar 2019 21:04:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dz1K0sFe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726603AbfCBVEE (ORCPT ); Sat, 2 Mar 2019 16:04:04 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44678 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726529AbfCBVEE (ORCPT ); Sat, 2 Mar 2019 16:04:04 -0500 Received: by mail-wr1-f67.google.com with SMTP id w2so1404339wrt.11 for ; Sat, 02 Mar 2019 13:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+T5m1hyBNarWwTcvykLNAMGLk757w6MkFnFIa/3o+lg=; b=dz1K0sFes9fDPhvzIarYrO5iRR8CE2n1GvfQ4QIlt3E1OFHcT1oLdAAylOBCf2CNy7 VCdWDcFI9kooN6mbSUhMl5oBSAyd2MXyPq1N7jWci1gUNJQW/xwqtb5xNrrbf5sHQ+RR t8UH4Rsc+T6aUlZxl42CQgURGIkjb4K1INWH/9+Bm2ED5WnH4qgG1YpLS/IoxH6iINo2 KnAsyCq2+aMdNxvPFF4mDiymzR/XxZlYq++lGdAWxS1ZXFvxIl1m/+jjnoloP5EEK49i xaE6Y/S1Ds6FkY3XxOltKsKwknQOig8PNjoO1fg4cFw+U5XMKD8xTdk805vR0jbvBTss wC9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+T5m1hyBNarWwTcvykLNAMGLk757w6MkFnFIa/3o+lg=; b=tFxRi/kH9O/nCeY8fwQhp114z0HQfr2pMPT6N1433NMtVh/32iTm1TEglJ0J8zBpSQ pXUMZWczyadatpp3DfdWxX6SWEzGRXL0X75rjDCkcH+Bsp0IRTBRWd57JdoASmsJmUix XI5jkpJ91XZWJOAycB8/Blk4Iasd8XynFb58j+nAFr42k6b//3IW/QEziZcMNWspOjT4 Lg5BS2mAaAIU5vIK1tQ+7WGCoKBwcYogt6HbBuPH/lcp+sU4kbvLaqFaiC44SZ3HXa6/ Ffk1jSQQRqm7mAhZlT2Tu910k2QtXSUeqqgTcfs2wRYKSae9Kj+NCIqgN+c+tbmRPL9C CpOA== X-Gm-Message-State: APjAAAVRGhn+7vl6Crb/XEEt6A2NRx1+1AJKHo8hw2vBk6oc3nu2KHBO 8EtzGDett9O13lG5/rsp4QAp6LqW X-Google-Smtp-Source: APXvYqyd2TIXOCF1Ns8A8SFsjFLHgkKPPL4PGuVTfiALFT20AbVkV54o3S3/ys3ieAgGrf8oJOk0RA== X-Received: by 2002:adf:e385:: with SMTP id e5mr7929997wrm.267.1551560642256; Sat, 02 Mar 2019 13:04:02 -0800 (PST) Received: from ?IPv6:2003:ea:8bf1:e200:ed04:ce8:ead3:a1ec? (p200300EA8BF1E200ED040CE8EAD3A1EC.dip0.t-ipconnect.de. [2003:ea:8bf1:e200:ed04:ce8:ead3:a1ec]) by smtp.googlemail.com with ESMTPSA id p6sm6555886wre.63.2019.03.02.13.04.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 13:04:01 -0800 (PST) Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: support in-band signalling with external PHY for 1000BaseX/2500BaseX To: Andrew Lunn Cc: Vivien Didelot , Florian Fainelli , David Miller , "netdev@vger.kernel.org" References: <20190302201307.GA10359@lunn.ch> <20190302204546.GC10359@lunn.ch> From: Heiner Kallweit Message-ID: <8f81bd4f-e4b5-7abd-5f20-3b812b55a9f5@gmail.com> Date: Sat, 2 Mar 2019 22:03:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190302204546.GC10359@lunn.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02.03.2019 21:45, Andrew Lunn wrote: >> I briefly looked at the SFP connector and there don't seem to be pins for >> out-of-band signalling. So there must be some inband signalling. > > Hi Heiner > > Optical SFPs have an i2c bus with an 'EEPROM' on it. The EEPROM > contains information about the SFP, including its maximum > bit-rate. The Linux SFP driver will look at this bitrate, and pick the > link mode appropriate to it. It then calls mac_config with that link > mode, and the link speed. > I briefly looked at the sfp phy driver and it doesn't seem to use phylink. So maybe the code in question is needed only if phylink is involved. As Russell wrote phylink may not yet fully support use case [Switch port MAC] <--> [SERDES PHY] <--> [External PHY] He sketched a few ideas. > The MAC then needs to configure the SERDES to that mode/speed. After a > while, it will get sync and trigger an interrupt. At is then reported > via phylink_mac_change() at which point the carrier is indicated as > up. If one end is using 1000Base-X and the other 2500Base-X, they will > fail to sync. There is no negotiation down to 1000Base-X. > > Optical SFPs are pretty passive devices, they just do electrical to > optical, and not a lot more. All the 'intelligence' is in the SERDES > layers, and they talk to each other end-to-end, unlike copper, where > the MAC SERDES is talking to the PHY SERDES. > > Copper SFPs are different. They use SGMII with inband signalling. > There is also a mechanism to encapsulate MDIO over i2c. > Good to know. Again something learnt. So there may be cases where the code we talk about isn't needed. But if let's say a 2.5Gbps copper PHY is connected to port 9 of a 88E6390 (like the Aquantia PHY), then 2500BaseX is used and I think the code is needed, or? > Andrew > Heiner