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=-3.8 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 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 83D4BC388F9 for ; Fri, 20 Nov 2020 00:13:57 +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 0CF4C20888 for ; Fri, 20 Nov 2020 00:13:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cYNcGc7L"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=waldekranz-com.20150623.gappssmtp.com header.i=@waldekranz-com.20150623.gappssmtp.com header.b="Jlwjh1HK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CF4C20888 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=waldekranz.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:Message-ID:Date:References:In-Reply-To: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=iYYnhsHPxvNC9F+ch+zhG/I3Wmsd+WZkV1WGcldI7RA=; b=cYNcGc7LOn8Lnu5deEjL9QLFU tehLHnSDjhgYfFdTOfEG4HhRuzYuHt1VP9EbnVhV53/h7Rip+eCxOxPprf7Qh1NzT1pgT1cS3dq09 Cr7UCPDgzY4RYwzNHD20XGJw0XBIn6WdYqLlDB54QzU/vnZK6BxuehiILxpSYK4i6cW+0JMdldE6P kKS+Hr3zSvxpR38t/yJQUcFUyviZTjrhwZrqXNQBl/X5cnqzIa4+gaNHKPNCvXKkvpSNLsE2zFF6R G/RHMIpyhLKcF4sF70DRv9QXvYQWzsRSHHqP138r4CTpRtdQklabBAOZX9kJurKo/HEQoSE5UdEX/ Ck64Km4lg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfu1K-0004qA-Tc; Fri, 20 Nov 2020 00:11:22 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfu1E-0004pe-0Q for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 00:11:21 +0000 Received: by mail-lj1-x229.google.com with SMTP id 142so8181865ljj.10 for ; Thu, 19 Nov 2020 16:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Clrk8WAuDZaq9eqOlyszSWbtlAidCiQ/pqctCxtmCeM=; b=Jlwjh1HKMA3xftnW+dDq22JGh9afs4iZCYDNmyjL+oNg+RQV3p6THWM4vIvtRtkK4d GrB2LtXIJxcipyr1W/ptoRtL/RIIaaCno0YjvKPZNOIOvi1DWXZrYVZJ7U6+l/k7A21y 6jhMcWkiVQ8MPlY2BbzaDhYP0vmt6ACdaXWxObFkWoQ7NVyRL01iIoIMWIJoPe/RtndN /FdfqAVqtMFnOIHruq1vWt/dFt93NFAq9cGdrjlq3FaJ1kt5dQzu4mTrfL9KNJE/Afsp TqikED9lNlHeFoqputsZtm6fAOpNtj2KPIDswBo2LJOzSlcQkrS5egWQA4GhGy8C5QIZ MrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Clrk8WAuDZaq9eqOlyszSWbtlAidCiQ/pqctCxtmCeM=; b=TAOexjkbksSp5adxrEKfSksXAKP+vMHKdwzh+Ogje9qQ1nemX/JJcSmGC181SLo/TA +vmiQ+pUTBFFY30RqO2726QYagyUnpL+OXYQVXEcf7vpI/BO7Xq6iUq9D6IyXVGNWM1s auFcfWu0NPZHFIUbWIAA8Dai4SIRlwBmnubhdsS0rS/l3HX7Y8yYl0teXzzK/DkJ58cJ GHGjKvY2VxPXxqYgsXXKssQ8YQnjtob8dzrGTC5Ejbk4VmrfQGEZp2ze6jUk4t5ijCYO pr+20c7w4TQAAKmqX8rjl9iQR4guZU8byWr9496kbpY8C1CCUG2Y6owKeAMt3U1TWNWH NgVg== X-Gm-Message-State: AOAM530tvjGFjlZtQOw/2Hoa0rQpeUxBZfEDD/hC/JRUyv1Wa34O9lTk GAZ3VRYzBzRBAdlXdWlYkrRxIZ9q2rEEINCq X-Google-Smtp-Source: ABdhPJzHKrEagljT+wr7hl7Li5Pu+TdYLu889OzAws1ROlq27vd5EUEVgt08NkvSZ9JIh2Yqt3yd1w== X-Received: by 2002:a2e:a17c:: with SMTP id u28mr7161458ljl.453.1605831073802; Thu, 19 Nov 2020 16:11:13 -0800 (PST) Received: from wkz-x280 (h-79-28.A259.priv.bahnhof.se. [79.136.79.28]) by smtp.gmail.com with ESMTPSA id o3sm145174lfo.217.2020.11.19.16.11.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 16:11:13 -0800 (PST) From: Tobias Waldekranz To: Russell King - ARM Linux admin Subject: Re: net: phy: Dealing with 88e1543 dual-port mode In-Reply-To: <20201119231613.GN1551@shell.armlinux.org.uk> 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> Date: Fri, 20 Nov 2020 01:11:12 +0100 Message-ID: <87eekoanvj.fsf@waldekranz.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_191116_198446_30A68D16 X-CRM114-Status: GOOD ( 25.91 ) 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 , Vivien Didelot , Thomas Petazzoni , Maxime Chevallier , "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 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>; }; }; 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 5CA09C63777 for ; Fri, 20 Nov 2020 00:11:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EA6DA22249 for ; Fri, 20 Nov 2020 00:11:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=waldekranz-com.20150623.gappssmtp.com header.i=@waldekranz-com.20150623.gappssmtp.com header.b="Jlwjh1HK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727140AbgKTALS (ORCPT ); Thu, 19 Nov 2020 19:11:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727115AbgKTALR (ORCPT ); Thu, 19 Nov 2020 19:11:17 -0500 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69DC0C0613CF for ; Thu, 19 Nov 2020 16:11:15 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id h23so8164228ljg.13 for ; Thu, 19 Nov 2020 16:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Clrk8WAuDZaq9eqOlyszSWbtlAidCiQ/pqctCxtmCeM=; b=Jlwjh1HKMA3xftnW+dDq22JGh9afs4iZCYDNmyjL+oNg+RQV3p6THWM4vIvtRtkK4d GrB2LtXIJxcipyr1W/ptoRtL/RIIaaCno0YjvKPZNOIOvi1DWXZrYVZJ7U6+l/k7A21y 6jhMcWkiVQ8MPlY2BbzaDhYP0vmt6ACdaXWxObFkWoQ7NVyRL01iIoIMWIJoPe/RtndN /FdfqAVqtMFnOIHruq1vWt/dFt93NFAq9cGdrjlq3FaJ1kt5dQzu4mTrfL9KNJE/Afsp TqikED9lNlHeFoqputsZtm6fAOpNtj2KPIDswBo2LJOzSlcQkrS5egWQA4GhGy8C5QIZ MrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Clrk8WAuDZaq9eqOlyszSWbtlAidCiQ/pqctCxtmCeM=; b=i3AKQZg3hjg2WsV5+zh6Mp+cY0tZ2O/l4mlf7Y07HC7qmGoRs+qg4rBqArNGFe0TAm K6h5vwRInlT/n5sI2pVe234uaNmTPEEar9l1ZWY0oULsHFfACrHwIfauu9qDVBkjgz8l dj4tlrixgoQV0aIsbTD1jG0YACuif7zSBWSBcuWlJVqMDW1fdQfY24yqGRfIwE85ejdl mab+m5KDAaLdTzEO0rpGl8BDeSngKJTYRyFELkDSY+OqG6MNMrnZ0ezX2Phqk4R1qpjM FETfqrI7tdUcU6aDTFLbeHgsJ8excU21nF7M0eV7QwIpZf143h+sJbJ+nTNyZLuI8xDE SIeQ== X-Gm-Message-State: AOAM532sqwTqwZiXE5TvWULZw8KITaye/30UgTtOhSTRhIyc70Y5fL4X VEeLW5VN8JupZMcaMhaqMh0DOA== X-Google-Smtp-Source: ABdhPJzHKrEagljT+wr7hl7Li5Pu+TdYLu889OzAws1ROlq27vd5EUEVgt08NkvSZ9JIh2Yqt3yd1w== X-Received: by 2002:a2e:a17c:: with SMTP id u28mr7161458ljl.453.1605831073802; Thu, 19 Nov 2020 16:11:13 -0800 (PST) Received: from wkz-x280 (h-79-28.A259.priv.bahnhof.se. [79.136.79.28]) by smtp.gmail.com with ESMTPSA id o3sm145174lfo.217.2020.11.19.16.11.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 16:11:13 -0800 (PST) From: Tobias Waldekranz To: Russell King - ARM Linux admin Cc: Maxime Chevallier , Andrew Lunn , Vivien Didelot , Florian Fainelli , Heiner Kallweit , "David S. Miller" , Antoine Tenart , Thomas Petazzoni , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: net: phy: Dealing with 88e1543 dual-port mode In-Reply-To: <20201119231613.GN1551@shell.armlinux.org.uk> 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> Date: Fri, 20 Nov 2020 01:11:12 +0100 Message-ID: <87eekoanvj.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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>; }; }; 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.