Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737AbdHVQkf (ORCPT ); Tue, 22 Aug 2017 12:40:35 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:37158 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751043AbdHVQkd (ORCPT ); Tue, 22 Aug 2017 12:40:33 -0400 Subject: Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac To: Chen-Yu Tsai , Andrew Lunn Cc: Maxime Ripard , Corentin Labbe , Rob Herring , Mark Rutland , Russell King , Giuseppe Cavallaro , Alexandre Torgue , devicetree , linux-arm-kernel , linux-kernel , netdev References: <20170818122118.4925-1-clabbe.montjoie@gmail.com> <20170818122118.4925-4-clabbe.montjoie@gmail.com> <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> From: Florian Fainelli Message-ID: Date: Tue, 22 Aug 2017 09:40:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3537 Lines: 77 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? -- Florian