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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 B9B29C43381 for ; Sat, 2 Mar 2019 20:45:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74C7E20838 for ; Sat, 2 Mar 2019 20:45:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="vJZH3nAR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726603AbfCBUpw (ORCPT ); Sat, 2 Mar 2019 15:45:52 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:44574 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726529AbfCBUpv (ORCPT ); Sat, 2 Mar 2019 15:45:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eQgj0RKec/t5VX6FXn4icZbfSp+JfgB8HATWwd6kWsU=; b=vJZH3nAR2oNXRQ8BxH4P7flPc2 +CbhwtEX/lJPp632ASu4yxmXJqIWHjLe8h5Pd+KAjxDr0DLUAQL8ZgZUOj/EWdma4j5qalmNe1PGZ 5au4q3I1+EqDgmNnVnLVST399rpotzIpVvHaBNiz2HxxCSBu57mlC4QEfPYUmkqristw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1h0BVy-0004hb-SP; Sat, 02 Mar 2019 21:45:46 +0100 Date: Sat, 2 Mar 2019 21:45:46 +0100 From: Andrew Lunn To: Heiner Kallweit Cc: Vivien Didelot , Florian Fainelli , David Miller , "netdev@vger.kernel.org" Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: support in-band signalling with external PHY for 1000BaseX/2500BaseX Message-ID: <20190302204546.GC10359@lunn.ch> References: <20190302201307.GA10359@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > 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. 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. Andrew