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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83ACBC04A6A for ; Tue, 8 Aug 2023 19:26:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235350AbjHHT0L (ORCPT ); Tue, 8 Aug 2023 15:26:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234211AbjHHTZz (ORCPT ); Tue, 8 Aug 2023 15:25:55 -0400 Received: from pandora.armlinux.org.uk (unknown [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FBE180B1; Tue, 8 Aug 2023 11:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To: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=2g3utr/eujTjRaQIcLvNeTDh3WTi5rEqtO34hdQFdT0=; b=feMXlHseapYWghPVTJHdmZssl3 eciqABRWVwnQp/E6K8PCedielRvsbcw4dRtXbsJx9wtIOcfBcpecqr/Y96PrFtlqGbw/fvpeARePk VrGvx1L8Iwxkwl+oLu6WfXlu3s1MZGJIvGQPEKIlPBx0wBjc8R9IPt+gOkpP/1lxZy9/VtXdc6iHC tVaH1INRn4PlNVJyzqGt+Fll1SHqzz/MY1vONsQEelXeVHjjRwLia+738lj2OdLLU41e9LnLmpwCN W0VzF58ExqPFfhCeMBahj4E2RyFvg3Q3Ozf5g99pcX/bp7OmeyhlW3uTx4hM6/JqRh312Dn/KsWCn 8g3m1x+g==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47552) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qTOLw-00009S-1Q; Tue, 08 Aug 2023 16:10:34 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qTOLu-0008DC-75; Tue, 08 Aug 2023 16:10:30 +0100 Date: Tue, 8 Aug 2023 16:10:30 +0100 From: "Russell King (Oracle)" To: Andrew Halaney Cc: Bartosz Golaszewski , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Alexandre Torgue , Jose Abreu , Maxime Coquelin , Alex Elder , Srini Kandagatla , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, Bartosz Golaszewski Subject: Re: [PATCH 0/2] net: stmmac: allow sharing MDIO lines Message-ID: References: <20230807193102.6374-1-brgl@bgdev.pl> <54421791-75fa-4ed3-8432-e21184556cde@lunn.ch> <65b53003-23cf-40fa-b9d7-f0dbb45a4cb2@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Aug 08, 2023 at 09:44:16AM -0500, Andrew Halaney wrote: > On Tue, Aug 08, 2023 at 04:30:05PM +0200, Bartosz Golaszewski wrote: > > On Tue, Aug 8, 2023 at 4:25 PM Andrew Lunn wrote: > > > > > > > > On Tue, Aug 08, 2023 at 10:13:09AM +0200, Bartosz Golaszewski wrote: > > > > > > Ok so upon some further investigation, the actual culprit is in stmmac > > > > > > platform code - it always tries to register an MDIO bus - independent > > > > > > of whether there is an actual mdio child node - unless the MAC is > > > > > > marked explicitly as having a fixed-link. > > > > > > > > > > > > When I fixed that, MAC1's probe is correctly deferred until MAC0 has > > > > > > created the MDIO bus. > > > > > > > > > > > > Even so, isn't it useful to actually reference the shared MDIO bus in some way? > > > > > > > > > > > > If the schematics look something like this: > > > > > > > > > > > > -------- ------- > > > > > > | MAC0 |--MDIO-----| PHY | > > > > > > -------- | | ------- > > > > > > | | > > > > > > -------- | | ------- > > > > > > | MAC1 |-- ----| PHY | > > > > > > -------- ------- > > > > > > > > > > > > Then it would make sense to model it on the device tree? > > > > > > > > > > So I think what you're saying is that MAC0 and MAC1's have MDIO bus > > > > > masters, and the hardware designer decided to tie both together to > > > > > a single set of clock and data lines, which then go to two PHYs. > > > > > > > > The schematics I have are not very clear on that, but now that you > > > > mention this, it's most likely the case. > > > > > > I hope not. That would be very broken. As Russell pointed out, MDIO is > > > not multi-master. You need to check with the hardware designer if the > > > schematics are not clear. > > > > Sorry, it was not very clear. It's the case that two MDIO masters > > share the MDC and data lines. > > I'll make the water muddier (hopefully clearer?). I have access to the > board schematic (not SIP/SOM stuff though), but that should help here. > > MAC0 owns its own MDIO bus (we'll call it MDIO0). It is pinmuxed to > gpio8/gpio9 for mdc/mdio. MAC1 owns its own bus (MDIO1) which is > pinmuxed to gpio21/22. > > On MDIO0 there are two SGMII ethernet phys. One is connected to MAC0, > one is connected to MAC1. > > MDIO1 is not connected to anything on the board. So there is only one > MDIO master, MAC0 on MDIO0, and it manages the ethernet phy for both > MAC0/MAC1. > > Does that make sense? I don't think from a hardware design standpoint > this is violating anything, it isn't a multimaster setup on MDIO. That all sounds sane, thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!