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 6E2DCC001DB for ; Tue, 8 Aug 2023 21:14:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236250AbjHHVOa (ORCPT ); Tue, 8 Aug 2023 17:14:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236256AbjHHVOT (ORCPT ); Tue, 8 Aug 2023 17:14:19 -0400 Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51681FE5E for ; Tue, 8 Aug 2023 11:26:34 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-79a2216a22fso1592716241.0 for ; Tue, 08 Aug 2023 11:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20221208.gappssmtp.com; s=20221208; t=1691519193; x=1692123993; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NbSuxAH1dmgDI1cFhSw3+FjHgNgeooTpwVKeZW63XUA=; b=omX3M6W7HI4CkdKEejiKetClW4YUWnvCPUq8gKc/AoVUAnqTLGguQDDx/Sp7R778JN J9TSo32CN6hMaWQKcsB0qNqnAfUmpGbESPtgNucK5ozybmP7dGop+fVUtC7USzhv0x20 JypPvqhLY7OCKJtBcfnX+96fYG5NsovjpKeVeQyTpMIw8hCNkqz97Nj5+31R97GKArfx FvTCBQ21Dt/3FRicqjABaU4W4VS+jqKz5MgCjjWoW7/8fz5NgBnX8wQtxRvChUJ90vs8 M6mrEFvM5V+hgB099+64rLexf3D68SYLB6togDUSjQ9USqOosVkxu49B4wTl+yHLi33a 3Kiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691519193; x=1692123993; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NbSuxAH1dmgDI1cFhSw3+FjHgNgeooTpwVKeZW63XUA=; b=dBwYhNn4ejUd1aQWDUvQs/CRQNfj73jhnno4zv5Pb0oo+qKpvSH220/x5dhHCAMg9w OxfR6aaxzrWrBTVqd6TLyn4MHsxycAkerZvKfxhTzYTDCg7sh7Sbhglf259TWI5wAxs5 7hXhDsaOHHdPnmTZGr7WCvgjk61SK2974s6kPWUVEQmrdxGyqu/1qg8F0jBH+OB0rnwC hH2ph9wbZPhfskhexNLjZiDr+93paliwH6tV1GkX5AIPkz5xJBG1Qpmo07vm7ykneXVs ahH/dQWe7GNsl+HLTX/uNWpAyP2R/PwHXHdZ0GANWjBuSK0NCHg17MZY3RokXc1NHE3B vR8g== X-Gm-Message-State: AOJu0YwI3XgH5cvqfScSEtLloICTO4KiNeUEVUnqmYb3Lc7bfVLh/+YL WNCuBsmAIE0bJmDdGJK8l6p92K/Xyc/oA5+HwhyumQ== X-Google-Smtp-Source: AGHT+IG8ilz+lyyZPz/QTN9yYwu4PQ8UFXiUmVfIAYHkY7cO5/Ehx+F7e2EvG0Tpci9f03MzRW/uy/lDk0h8r21yu9I= X-Received: by 2002:a67:f905:0:b0:443:677e:246e with SMTP id t5-20020a67f905000000b00443677e246emr716156vsq.5.1691519193393; Tue, 08 Aug 2023 11:26:33 -0700 (PDT) MIME-Version: 1.0 References: <20230807193102.6374-1-brgl@bgdev.pl> <54421791-75fa-4ed3-8432-e21184556cde@lunn.ch> <65b53003-23cf-40fa-b9d7-f0dbb45a4cb2@lunn.ch> In-Reply-To: From: Bartosz Golaszewski Date: Tue, 8 Aug 2023 20:26:22 +0200 Message-ID: Subject: Re: [PATCH 0/2] net: stmmac: allow sharing MDIO lines To: Andrew Lunn Cc: Andrew Halaney , "Russell King (Oracle)" , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Aug 8, 2023 at 5:15=E2=80=AFPM Andrew Lunn wrote: > > > 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. > > Thanks for taking a detailed look at the schematics. This is how i > would expect it to be. > > > > > > Good point, but it's worse than that: when MAC0 is unbound, it wi= ll > > > > > unregister the MDIO bus and destroy all PHY devices. These are no= t > > > > > refcounted so they will literally go from under MAC1. Not sure ho= w > > > > > this can be dealt with? > > > > > > > > unbinding is not a normal operation. So i would just live with it, = and > > > > if root decides to shoot herself in the foot, that is her choice. > > > > > > > > > > I disagree. Unbinding is very much a normal operation. > > What do you use it for? > > I don't think i've ever manually done it. Maybe as part of a script to > unbind the FTDI driver from an FTDI device in order to use user space > tools to program the EEPROM? But that is about it. > > I actually expect many unbind operations are broken because it is very > rarely used. > When I say "device unbind", I don't just mean manual unbinding using sysfs. I mean any code path (rmmod, unplugging the USB, etc.) that leads to the device being detached from its driver. This is a perfectly normal situation and should work correctly. I won't be fixing it for this series but may end up looking into establishing some kind of device links between MACs and their "remote" PHYs that would allow to safely unbind them. Bart