From patchwork Tue Aug 22 18:11:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Corentin Labbe X-Patchwork-Id: 9915881 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8A88F600C5 for ; Tue, 22 Aug 2017 18:12:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 708F3288F1 for ; Tue, 22 Aug 2017 18:12:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6531A288E8; Tue, 22 Aug 2017 18:12:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id CFE7928913 for ; Tue, 22 Aug 2017 18:12:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: 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=UVLmaFzzakCgyVnk78dpjhf73JDzjnuPNhKraNCWyus=; b=rCtGQZwwBCMA1G 4lT8YVmXf55UbeJZb2ykY44UQnFNoP1AtIN7nfoHORkkKIqXt+mhWjRH6DqNbRZHyPivmyR6lqXxQ Xv1TV13NOSt8EJGrm6qvOqksGVFNA0EmTTdMRvrCxQJK9J0+IxGiiRyA+IbnOuTHDhgJfQ6uT+Qv1 dCAFwVOHx+cJHqQnE/XiJM1E6XtGkOfo4RZFf4wY3imUE2jY+55TOfExBX/TOwXV1luLoM9fSpcox OMfKv2J1JaQ7o8zqxqqnOtO5ukQa68GzWwAVSxM/oDJ+eUAZ7YqfXpBUnsr9+/x8dGhv5GWTzpxNM 85eTo1YGxVsBTJUhvuAQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dkDew-0002cX-Hn; Tue, 22 Aug 2017 18:12:14 +0000 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dkDes-0002XI-Ep for linux-arm-kernel@lists.infradead.org; Tue, 22 Aug 2017 18:12:12 +0000 Received: by mail-wm0-x244.google.com with SMTP id y206so9277527wmd.5 for ; Tue, 22 Aug 2017 11:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+8scy55slXx8/eh8qdkKsU7Ix8sBrmlkP4qSkMHK5r8=; b=oSjhlYVOLTVErgKCMBbhEmTuzfCfDVRxF4VfSmSp51zXqKfsb9JOFNPjqn/tcxIzTP OUBI3mW4wlF9oOyxQKfpZax32KMRSu+MAeKY+XzmIRDwPolLqTs93DvElWh1ttU7jl85 wmK8dnHVe/XqzZUSrU9FTuTTPo+GtcJEqZ+SU+qB5NiA4mDF0v/NHtUdmbTmxNHI2c/7 i5aWdV0g5NmKAywnCKSuXF0zq2JXcmw0jeiKNDnsA/bH9//xoYljxGF6M2WaPswqV1lg +TNhGbIfT7ia/JJiPpCCk0iHTe6xE4Z+lbFa1t2gudLwXGFeNeSWlI190nyUB0AooRi2 9jxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+8scy55slXx8/eh8qdkKsU7Ix8sBrmlkP4qSkMHK5r8=; b=qb1azob++KvQgngVmJ0sL4cIud8qhNYiovEcWJ7ideM5ROtYvl+ybHHgrLBIDDsap4 pIzN9A3j08fnTok6hysPJHIbpptxh0Fc+tXqGA5RvZtc6lobvNnZguKXkH7DwRQ7g6oZ o3KbqC8EzWPjt6rx7y9/82dK4k4WtDBMOwhq++FAiicb4DYiEigxOQshMXjUOWT5gvyz wikUD6y1gFfCPSmCnZyyxYBG7XtVxtEppc9cU6KLlzWDyI+8edEw3+UFcMD2u639O/uD 4VoylmlQqFNbD9URwd9T79UmlGXzbUm3C+wMh0yxwK8sKcAZFvBLkvUXTED5ww2UB9wY 1BNQ== X-Gm-Message-State: AHYfb5h/u0kFoWLhQD34mCDnFMq2Arnz+daBSFEWhlB8HDsWDJBpTM/W 0cXC4o++tNvaxA== X-Received: by 10.28.157.81 with SMTP id g78mr247606wme.85.1503425508586; Tue, 22 Aug 2017 11:11:48 -0700 (PDT) Received: from Red ([2a01:cb1d:16e:1300:2e56:dcff:fed2:c6d6]) by smtp.googlemail.com with ESMTPSA id g133sm17244607wmd.48.2017.08.22.11.11.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 11:11:47 -0700 (PDT) Date: Tue, 22 Aug 2017 20:11:40 +0200 From: Corentin Labbe To: Florian Fainelli Subject: Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac Message-ID: <20170822181140.GA11596@Red> References: <20170819185025.GB13266@Red> <20170819203836.GA21567@lunn.ch> <20170820065757.GA6081@Red> <20170820142545.GB24150@lunn.ch> <20170821132015.GB1703@lunn.ch> <20170821133104.qvrhvwin2rdg4aqo@flea.lan> <20170821142321.GE1703@lunn.ch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170822_111210_705954_93B1B9D3 X-CRM114-Status: GOOD ( 31.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Andrew Lunn , Alexandre Torgue , devicetree , netdev , Russell King , linux-kernel , Chen-Yu Tsai , Rob Herring , Giuseppe Cavallaro , Maxime Ripard , linux-arm-kernel Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Aug 22, 2017 at 09:40:24AM -0700, Florian Fainelli wrote: > On 08/22/2017 08:39 AM, Chen-Yu Tsai wrote: > > On Mon, Aug 21, 2017 at 10:23 PM, Andrew Lunn wrote: > >>> All muxes are mostly always represented the same way afaik, or do you > >>> want to simply introduce a new compatible / property? > >> > >> + mdio-mux { > >> + compatible = "allwinner,sun8i-h3-mdio-switch"; > >> + mdio-parent-bus = <&mdio_parent>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + internal_mdio: mdio@1 { > >> reg = <1>; > >> - clocks = <&ccu CLK_BUS_EPHY>; > >> - resets = <&ccu RST_BUS_EPHY>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + int_mii_phy: ethernet-phy@1 { > >> + compatible = "ethernet-phy-ieee802.3-c22"; > >> + reg = <1>; > >> + clocks = <&ccu CLK_BUS_EPHY>; > >> + resets = <&ccu RST_BUS_EPHY>; > >> + phy-is-integrated; > >> + }; > >> + }; > >> + mdio: mdio@0 { > >> + reg = <0>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> }; > >> > >> Hi Maxim > >> > >> Anybody who knows the MDIO-mux code/binding, knows that it is a run > >> time mux. You swap the mux per MDIO transaction. You can access all > >> the PHY and switches on the mux'ed MDIO bus. > >> > >> However here, it is effectively a boot-time MUX. You cannot change it > >> on the fly. What happens when somebody has a phandle to a PHY on the > >> internal and a phandle to a phy on the external? Does the driver at > >> least return -EINVAL, or -EBUSY? Is there a representation which > >> eliminates this possibility? > > > > There is only one controller. Either you use the internal PHY, which > > is then directly coupled (no magnetics needed) to the RJ45 port, or > > you use an external PHY over MII/RMII/RGMII. You could supposedly > > have both on a board, and let the user choose one. But why bother > > with the extra complexity and cost? Either you use the internal PHY > > at 100M, or an external RGMII PHY for gigabit speeds. > > I agree, there is no point in over-engineering any of this. I don't > think there is actually any MDIO mux per-se in that the MDIO clock and > data lines are muxed, however there has to be some kind of built-in port > multiplexer that lets you chose between connecting to the internal PHY > and any external PHY/MAC, but that is not what a "mdio-mux" node represents. > > > > > So I think what you are saying is either impossible or engineering-wise > > a very stupid design, like using an external MAC with a discrete PHY > > connected to the internal MAC's MDIO bus, while using the internal MAC > > with the internal PHY. > > > > Now can we please decide on something? We're a week and a half from > > the 4.13 release. If mdio-mux is wrong, then we could have two mdio > > nodes (internal-mdio & external-mdio). > > I really don't see a need for a mdio-mux in the first place, just have > one MDIO controller (current state) sub-node which describes the > built-in STMMAC MDIO controller and declare the internal PHY as a child > node (along with 'phy-is-integrated'). If a different configuration is > used, then just put the external PHY as a child node there. > > If fixed-link is required, the mdio node becomes unused anyway. > > Works for everyone? If we put an external PHY with reg=1 as a child of internal MDIO, il will be merged with internal PHY node and get phy-is-integrated. Does two MDIO node "internal-mdio" and "mdio" works for you ? (We keep "mdio" for external MDIO for reducing the number of patchs) Thanks Regards diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index 4b599b5d26f6..d5e7cf0d9454 100644 --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi @@ -417,7 +417,8 @@ #size-cells = <0>; status = "disabled"; - mdio: mdio { + /* Only one MDIO is usable at the time */ + internal_mdio: mdio@1 { #address-cells = <1>; #size-cells = <0>; int_mii_phy: ethernet-phy@1 { @@ -425,8 +426,13 @@ reg = <1>; clocks = <&ccu CLK_BUS_EPHY>; resets = <&ccu RST_BUS_EPHY>; + phy-is-integrated; }; }; + mdio: mdio@0 { + #address-cells = <1>; + #size-cells = <0>; + }; }; spi0: spi@01c68000 {