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.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 53661C432C0 for ; Sun, 17 Nov 2019 19:25:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 23BB320718 for ; Sun, 17 Nov 2019 19:25:40 +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="jiX8arR4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726203AbfKQTZj (ORCPT ); Sun, 17 Nov 2019 14:25:39 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:43890 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726082AbfKQTZi (ORCPT ); Sun, 17 Nov 2019 14:25:38 -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=sWt1tNvr1hHhW++q0izT/c2B1CSr+bShfknH/cf5nAo=; b=jiX8arR42cBisSsv8P+O1hjee8 GFUko/fLReBeCRSseA4PuuTQZrkdKOpT65K6EJ4gt36dvM+lu7wV/xwtO570jMn0AifbQPo1GwAMM novUFdAWfmUtZAPkS9NmsbEIpA0um/mlii8B1Ss6W5gDsB7v90QSVARiykr8PMWP9hzc=; Received: from andrew by vps0.lunn.ch with local (Exim 4.92.2) (envelope-from ) id 1iWQAr-0001Qz-IG; Sun, 17 Nov 2019 20:25:29 +0100 Date: Sun, 17 Nov 2019 20:25:29 +0100 From: Andrew Lunn To: Russell King - ARM Linux admin Cc: Florian Fainelli , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: add SFP+ support Message-ID: <20191117192529.GB4084@lunn.ch> References: <20191115195339.GR25745@shell.armlinux.org.uk> <20191116160635.GB5653@lunn.ch> <20191116214042.GU25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191116214042.GU25745@shell.armlinux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > The answer is... it depends. Hi Russell One issue we have had with phylink is people using the interfaces wrongly. When asking this question, i was thinking about documentation. Your answer suggests this method is not simply about the validation you are doing here, it could also be about configuration of the PHY to fit the module. Maybe it would be good to add documentation somewhere about the range of things this call can do? > So, this patch reflects what can be done with the SFP+ slots on > Macchiatobin boards today. This all sounds very hardware dependent. So we are going to need some more DT properties i guess. Have you thought about this? Maybe we need to add compatibles sff,sfp+ and sff,sff+ ? Indicate the board is capable of the higher speeds? And when sfp+/sff+ is used, maybe a boolean to indicate it is also sff/sfp compatible? sfp_select_interface() can then look at these properties and return PHY_INTERFACE_MODE_NA if the board is not capable of supporting the module? Would it even make sense to make the PHY interface more like the MAC interface? A validate function to indicate what it is capable of? A configure function to configure its mode towards the SFP? Andrew