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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 D083BC63798 for ; Fri, 20 Nov 2020 09:37:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3B3AC223B0 for ; Fri, 20 Nov 2020 09:37:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sKDon/1O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B3AC223B0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XLHEp65p7IKC93C/v8sAEngtj7ZNvs6wt2kcNv90Vvw=; b=sKDon/1O3I1WQR0TuhkrIhthg N4TLPlSc3ScfzgHkbuyO9gcPZaAnjYaTf33ugU3OBpga0DRRQyghTVvY1KER0TPW1FYipvltGgNC6 HD/UcRVrgIg+JBoGu5ny0XKd5OuaiPenivs2V0DnqbBCKY7THanTnxsQ33i0BWQSARmRxNDRx6L7Z c5vvZ6BwJ+2u460i6UWzkC5w7uhjHKlGTwLpFRF7heq7IG0Ks8AeFLOnQ0ezf27WxafbdX6KKpSVJ uNvYVlS4br84MR9muTBNJHOwygdOfDH3LaOtXFmUjJk9JiBr2vzrGoRR61EuTWrO9R5gV0pEab+mr V+hhd1oAQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg2pw-000310-IO; Fri, 20 Nov 2020 09:36:12 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg2ps-0002zI-FF for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 09:36:10 +0000 X-Originating-IP: 90.55.104.168 Received: from bootlin.com (atoulouse-258-1-33-168.w90-55.abo.wanadoo.fr [90.55.104.168]) (Authenticated sender: maxime.chevallier@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 71CEEE0046; Fri, 20 Nov 2020 09:36:02 +0000 (UTC) Date: Fri, 20 Nov 2020 10:36:01 +0100 From: Maxime Chevallier To: Tobias Waldekranz Subject: Re: net: phy: Dealing with 88e1543 dual-port mode Message-ID: <20201120103601.313a166b@bootlin.com> In-Reply-To: <87eekoanvj.fsf@waldekranz.com> References: <20201119152246.085514e1@bootlin.com> <20201119145500.GL1551@shell.armlinux.org.uk> <20201119162451.4c8d220d@bootlin.com> <87k0uh9dd0.fsf@waldekranz.com> <20201119231613.GN1551@shell.armlinux.org.uk> <87eekoanvj.fsf@waldekranz.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201120_043608_740116_11B70B29 X-CRM114-Status: GOOD ( 25.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Florian Fainelli , netdev@vger.kernel.org, Antoine Tenart , Russell King - ARM Linux admin , Vivien Didelot , Thomas Petazzoni , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Heiner Kallweit Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Tobias, On Fri, 20 Nov 2020 01:11:12 +0100 Tobias Waldekranz wrote: >On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin wrote: >> On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote: >>> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier wrote: >>> > I don't think we have a way to distinguish from the DT if we are in >>> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is >>> > the same, we don't have any information in DT about wether or not the >>> > PHY is wired to a Copper RJ45 port. >>> > >>> > Maybe we should have a way to indicate if a PHY is wired to a Copper >>> > port in DT ? >>> >>> Do you mean something like: >>> >>> SGMII->SGMII (Fibre): >>> ethernet-phy@0 { >>> sfp = <&sfp0>; >>> }; >>> >>> SGMII->MDI (Copper): >>> ethernet-phy@0 { >>> mdi; >>> }; >>> >>> SGMII->Auto Media Detect >>> ethernet-phy@0 { >>> mdi; >>> sfp = <&sfp0>; >>> }; >> >> This isn't something we could realistically do - think about how many >> DT files are out there today which would not have this for an existing >> PHY. The default has to be that today's DT descriptions continue to work >> as-is, and that includes ones which already support copper and fibre >> either with or without a sfp property. >> >> So, we can't draw any conclusion about whether the fiber interface is >> wired from whether there is a sfp property or not. >> >> We also can't draw a conclusion about whether the copper side is wired >> using a "mdi" property, or whether there is a "sfp" property or not. >> >> The only thing we could realistically do today is to introduce a >> property like: >> >> mdi = "disabled" | "okay"; >> >> to indicate whether the copper port can be used, and maybe something >> similar for the fiber interface. Maybe as you suggest, not "okay" >> but specifying the number of connected pairs would be a good idea, >> or maybe that should be a separate property? > >Maybe you could have optional media nodes under the PHY instead, so that >you don't involve the SFP property in the logic (SGMII can be connected >to lots of things after all): > > ethernet-phy@0 { > ... > > sgmii { > status = "okay"; > preferred; > }; > > mdi { > status = "okay"; > pairs = <2>; > }; > }; I like that approach too, and I agree that we do need to be very careful with not breaking existing PHYs, where most of the time we assume that a PHY simply has a 8P8C (RJ45) connector. Maybe the term MDI is a bit misused here, my understanding was that MDI, standing for "Media Dependent Interface" represents the media-side interface in general, and not a particular technology such as xxxBaseT/X/K or Copper of Fibre. So maybe we could be a bit more generic, with something along these lines : ethernet-phy@0 { ... mdi { port@0 { media = "10baseT", "100baseT", "1000baseT"; pairs = <1>; }; port@1 { media = "1000baseX", "10gbaseR" }; }; }; This would allow us to explicitely indicate which modes are supported by each port. And in absence of the mdi node, we indeed fallback to the usual behaviour. >In the absence of any media declarations, you fall back to the driver's >default behavior (keeping compatibility with older DTs). But you can >still add support for more configurations if the information is >available. I also like the idea of having a way to express the "preferred" media, although I wonder if that's something we want to include in DT or that we would want to tweak at runtime, through ethtool for example. What do you think ? Thanks, Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel