Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp47659pxb; Thu, 2 Sep 2021 18:55:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy44k0wvUsOt0vL2zOo8XT94yY3WosTmHoi2+eYCckpg+KAEpiaLwpAf7vsshMokryZtdpC X-Received: by 2002:a05:6402:2909:: with SMTP id ee9mr1310285edb.377.1630634100344; Thu, 02 Sep 2021 18:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630634100; cv=none; d=google.com; s=arc-20160816; b=dh+9eSAzGB9sg/EZOCjbcUud21eTgrDI7nuR39nZv9IvL3g7Biv+B+WJFgjlpf4duM uplVbnqxR+bL9Tj8JqBfwkBlVD+cMqVoNWJ+HKK2ATJj4At3SHhJXmZHExOdm4rOxI1M jnEuoF59/mVf8uuQ+tukb2Dqov/bA8yY3yRxwhmrE6X89fRJMsB2YzHxcbE6ZHR+XrOr y7VrK+uCCE+fqTMjcRbJ56nI5LNN9KkOMWJuej1cQwoOBlCUNFl+avDCiKwVeltbs3cI IzKxo5irxkLYJKgQtdveFQv4dMFJ85espVAEX2QYWGPR+VsyyEEamPkfPMrxC3qLEEl2 aqPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=6xTg00PepVPylOtm1J0Y6rkZ7Wc4zH5g0ApsRZq0FUI=; b=gPAT6+9dPZo8KlNdLRyNP0R/RsmFKuUAqMk1KiZ37kCeErEnavxfqyv92EANxH/TYO EysboI5oS76aecdyTW0riDJctdWWlAih89X6yfAWqrEruyKPmxZPBg+r1KsLHAq9pbrl WaW3ocdr53tfQHVavxwAXP70LJpEH1pSFtq9/6vHbK9kVHilbkpW9AmlaQ2LJIaxIadG Thl+6hyRsWhtbqQ8466JebwNa19Y50xDAB7uXSdlO7Qyi/7b1iIbY2gIHjzfx4WYKEaO CmtIm+kJ45fMNN6h4MtssQGzYsngP5DAu797C7spUuRoA2yhrq3jfkDhvWkwZ+Davvcx +rnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=n0XEJv7U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gs20si1144880ejc.481.2021.09.02.18.54.37; Thu, 02 Sep 2021 18:55:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=n0XEJv7U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234496AbhIBXbC (ORCPT + 99 others); Thu, 2 Sep 2021 19:31:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233191AbhIBXbB (ORCPT ); Thu, 2 Sep 2021 19:31:01 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6ED13C061760 for ; Thu, 2 Sep 2021 16:30:02 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id k65so6907734yba.13 for ; Thu, 02 Sep 2021 16:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6xTg00PepVPylOtm1J0Y6rkZ7Wc4zH5g0ApsRZq0FUI=; b=n0XEJv7UdxOAcuracft+Xvw5QLLeajqnN5CBStW2IoBqQrqE1Dbq87vM10iYzXFByF kUaZoFC1HUuRs53G3sY8xqoEzzF0znynaeWGk0K4NlkxVzF375NsTwszhwJPQ/fLd5QE wDNFWc4sRuP44bSNwqAWirv21TiIhf/t/RQ4VnwmBrB85MFz4Sd2psvxdmin8UuwQjKV BmuvEzVXD1CJKZiwK/c2LdjhBveXGZZ9u4UEZ8RnKeBLujx7P69Uemzzhc4rWPxaoI4m nksWWTXfCGzbqYSGzFUNuSeq0v30pBFOHG99yWvFShn47nWm5dZS+jHyOZYEfCcbLbxL /daw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6xTg00PepVPylOtm1J0Y6rkZ7Wc4zH5g0ApsRZq0FUI=; b=PJSTObogAErvjAAAQoJuYtXtDrgorUbp2oLkRDGlmK6VwUioKaTIXgjflI9nGOpT8c 3sM3a3neG56XzWa1I/XoeqtUT2R0+lHwtLUF+mITaFPEn8T+JhpTyqvxKCEJ2Ozlmslr sZr2a8rUTUHY+kbhokxouoClnGnsvbwqMM9pBPOak6mp/4RRd2xRMIBeH9uP6VNan/Zb yX+qD1DAZQ9/KLR4cfroRhFHKtnT9NVxRZeeLpcB52+r06CG3eTAh1P9Cvy4V+veQSOj xaQ1OJdEurbkCuEHvKPO5TgcjWGQm/TFcB7SEHe6Ku10IBbzZXVG7kPn4ki1s+PwEKAP 4LAQ== X-Gm-Message-State: AOAM531zCk99aYUw5jYoCVha6apeLzlhg/PLPjk3h13wG3X502Ud/jcd QQy6W+i5g0Ihg5xgZbeBnTi50sW16EDXdiPkuwTVIA== X-Received: by 2002:a25:6746:: with SMTP id b67mr1341051ybc.96.1630625401243; Thu, 02 Sep 2021 16:30:01 -0700 (PDT) MIME-Version: 1.0 References: <20210901225053.1205571-1-vladimir.oltean@nxp.com> <20210902220520.hyybu6k3mjzbl7mn@skbuf> In-Reply-To: <20210902220520.hyybu6k3mjzbl7mn@skbuf> From: Saravana Kannan Date: Thu, 2 Sep 2021 16:29:25 -0700 Message-ID: Subject: Re: [RFC PATCH net-next 0/3] Make the PHY library stop being so greedy when binding the generic PHY driver To: Vladimir Oltean Cc: Vladimir Oltean , netdev@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Jakub Kicinski , Vivien Didelot , Florian Fainelli , linux-kernel@vger.kernel.org, Linus Walleij , =?UTF-8?Q?Alvin_=C5=A0ipraga?= , ACPI Devel Maling List , kernel-team , Len Brown Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 2, 2021 at 3:05 PM Vladimir Oltean wrote: > > On Thu, Sep 02, 2021 at 01:50:50AM +0300, Vladimir Oltean wrote: > > This is a continuation of the discussion on patch "[v1,1/2] driver core: > > fw_devlink: Add support for FWNODE_FLAG_BROKEN_PARENT" from here: > > https://patchwork.kernel.org/project/netdevbpf/patch/20210826074526.825517-2-saravanak@google.com/ > > > > Summary: in a complex combination of device dependencies which is not > > really relevant to what is being proposed here, DSA ends up calling > > phylink_of_phy_connect during a period in which the PHY driver goes > > through a series of probe deferral events. > > > > The central point of that discussion is that DSA seems "broken" for > > expecting the PHY driver to probe immediately on PHYs belonging to the > > internal MDIO buses of switches. A few suggestions were made about what > > to do, but some were not satisfactory and some did not solve the problem. > > > > In fact, fw_devlink, the mechanism that causes the PHY driver to defer > > probing in this particular case, has some significant "issues" too, but > > its "issues" are only in quotes "because at worst it'd allow a few > > unnecessary deferred probes": > > https://patchwork.kernel.org/project/netdevbpf/patch/20210826074526.825517-2-saravanak@google.com/#24418895 > > > > So if that's the criterion by which an issue is an issue, maybe we > > should take a step back and look at the bigger picture. > > > > There is nothing about the idea that a PHY might defer probing, or about > > the changes proposed here, that has anything with DSA. Furthermore, the > > changes done by this series solve the problem in the same way: "they > > allow a few unnecessary deferred probes" <- in this case they provoke > > this to the caller of phy_attach_direct. > > > > If we look at commit 16983507742c ("net: phy: probe PHY drivers > > synchronously"), we see that the PHY library expectation is for the PHY > > device to have a PHY driver bound to it as soon as device_add() finishes. > > > > Well, as it turns out, in case the PHY device has any supplier which is > > not ready, this is not possible, but that patch still seems to ensure > > that the process of binding a driver to the device has at least started. > > That process will continue for a while, and will race with > > phy_attach_direct calls, so we need to make the latter observe the fact > > that a driver is struggling to probe, and wait for it a bit more. > > > > What I've not tested is loading the PHY module at runtime, and seeing > > how phy_attach_direct behaves then. I expect that this change set will > > not alter the behavior in that case: the genphy will still bind to a > > device with no driver, and phy_attach_direct will not return -EPROBE_DEFER > > in that case. > > > > I might not be very versed in the device core/internals, but the patches > > make sense to me, and worked as intended from the first try on my system > > (Turris MOX with mv88e6xxx), which was modified to make the same "sins" > > as those called out in the thread above: > > > > - use PHY interrupts provided by the switch itself as an interrupt-controller > > - call of_mdiobus_register from setup() and not from probe(), so as to > > not circumvent fw_devlink's limitations, and still get to hit the PHY > > probe deferral conditions. > > > > So feedback and testing on other platforms is very appreciated. > > > > Vladimir Oltean (3): > > net: phy: don't bind genphy in phy_attach_direct if the specific > > driver defers probe > > net: dsa: destroy the phylink instance on any error in > > dsa_slave_phy_setup > > net: dsa: allow the phy_connect() call to return -EPROBE_DEFER > > > > drivers/base/dd.c | 21 +++++++++++++++++++-- > > drivers/net/phy/phy_device.c | 8 ++++++++ > > include/linux/device.h | 1 + > > net/dsa/dsa2.c | 2 ++ > > net/dsa/slave.c | 12 +++++------- > > 5 files changed, 35 insertions(+), 9 deletions(-) > > > > -- > > 2.25.1 > > > > Ouch, I just realized that Saravana, the person whose reaction I've been > waiting for the most, is not copied.... > > Saravana, you can find the thread here to sync up with what has been > discussed: > https://patchwork.kernel.org/project/netdevbpf/cover/20210901225053.1205571-1-vladimir.oltean@nxp.com/ Woah! The thread blew up. > > Sorry. No worries. I'll read through the thread later and maybe provide more responses, but one thing I wanted to say right away: Don't depend on dev->p->deferred_probe. It can be "empty" for a device that has returned -EPROBE_DEFER for a bunch of reasons: 1. When the device is in the middle of being reattempted, it would be empty. You can't hold any lock that'll ensure correctness either because deferred probe locking is a mess (I'm working on cleaning that up). 2. I'm working on actually not adding devices to that list if there's a known supplier that hasn't been probed yet. No point retrying it again and again for every deferred probe trigger when we know it's going to fail. And we'll basically get topological probe ordering. Your closest bet right now is d->can_match. Only caveat is that it's not cleared if the actual driver gets unregistered. -Saravana