Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1154756pxb; Wed, 10 Feb 2021 01:09:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJzG77tnA3sTAGHJttRGQpo3ozQhR0gHiRFNWJ7C5bSHds3yqjl2QPBl78HN+IR+xghcp4Wv X-Received: by 2002:a17:906:ca04:: with SMTP id jt4mr2047040ejb.548.1612948182079; Wed, 10 Feb 2021 01:09:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612948182; cv=none; d=google.com; s=arc-20160816; b=eQOYUKGzbaQ9rtbD12E7a2Z7crUpzkCg990u3nyMIutNfuhxQVrh7h/kfSrgf7QUjG UFilnXaSufnYjawnGV9QbMr4Ec0I6oyL6iOqSWCPM8BOXKghII9hR0ZiqLO/LraVVX3E XXx7V+ea6fsSd9XbB42qULCBaUq/XHDszOSUIxFZ+B6pxFNwbg2rWZ/0SheFhurvfWn8 vnw+5/3TlBMgJdgfUpw71YYZVqhwc+M+qT5JcnXYBHTwYZjhhTh1E/w9Z/Dj3SUPZqig EdJyKAwApQ0BTOcuzTX139VM2QA1tJmYCoOFstUox3GmHIy36Xj5S3ijYfZmrWXwDRKr o50A== 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=EIYUBkGMy3qE6aqOle/QpEgFxQFoJfY+aVajMelV3xs=; b=LQEerzaJklVX20O6qKnMAzXT/zP41EtdnKezvPGT9z9ayY3WPDy3Avb2FKzdhtZf53 CClvAwvStFDHKRIkqpAVnB5MGomXnUodRYWDJ3cSPP/7w0s70+t0B71HgcTllh9VEkg6 s4XkoHHPaz4/6THvWfMKPux9WrRebkAJEDCjRO5K4yJFl3TWm1yZqTCpJIFcToLJKFz+ igQAnD3wKZ01Vnbvqz0ZK1NlEbeht+//xReflIwGhLL1KtFh+lMFCXFDiCVPYyuiDyGH 1hfF2pDBGFnePdNatTshbCk7UtUOm3f7N9Q8k+kG3OANMgbfelwzJOUBn3oWnafyN0+S gEjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qqKG0XSv; 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 o7si982720eja.76.2021.02.10.01.09.15; Wed, 10 Feb 2021 01:09:42 -0800 (PST) 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=qqKG0XSv; 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 S229789AbhBJJCf (ORCPT + 99 others); Wed, 10 Feb 2021 04:02:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229798AbhBJI4M (ORCPT ); Wed, 10 Feb 2021 03:56:12 -0500 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4FB5C061788 for ; Wed, 10 Feb 2021 00:55:31 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id p186so1271717ybg.2 for ; Wed, 10 Feb 2021 00:55:31 -0800 (PST) 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=EIYUBkGMy3qE6aqOle/QpEgFxQFoJfY+aVajMelV3xs=; b=qqKG0XSv+akp+PhEDy+mWsosrzGxxmJtkSfE/RiAHtParBQ1+/HeO672kBHv8o8i3G eesnT9wcGJbvHbEc1b+g2cn0zA0r/mdAvB5O6SsxerFnvgsLpiD28pUxjoC2ILa9euYV xYnXmOzzgBvMfFgJOHoRR+nS/1qfbPS4DJMg3ElQZbbZMS9S72aPCJBFR1jKl5o7SEK9 gRY86ph1NI9lK898i7M4Bbmis02HInlo2BaYGfBFxcGzfZwvNSrCXXoPaZIT3IgxwxES KbI+yTrvPRW7RVetJNStLFzDlDblpefA1Q7CbbkLfvL9z8TfDasFOAyUL0v8uoBv3qq/ JRYA== 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=EIYUBkGMy3qE6aqOle/QpEgFxQFoJfY+aVajMelV3xs=; b=X3Vdmurf20p/DiM1Lgiw6Sod/d5hlPK0ay728hOHMGE713g8OlepAcTTT6iwZBoDPH DX1xHRgjf54aZCsYn+syx6ut8isPu1HAdPS0/u+fZMpaAq7qxjYgSvaTJUfuQwGaCZ5C viQxIaZvYIwC+WLJPDhxafeTYBr+CHwFC4u5WBV9+Vf/CL4HR92IDuQ7wwzmLMP13JE7 j2L1vzM0X+ywXl/+4HMEG443RM9kgLjPUzYDHoOqjHRM7oF72cIzC74N2Ak1RAdtdpjy 7L55HrWzYN+ye6kCE5Z/+YQWWwmxsQQkSv8x+1QQVEx4VLK5Un2TJdulE5qmXhMgiDtD Zc4w== X-Gm-Message-State: AOAM530QuGOI4pSvEYHcSZEOAdmxvOEZiViL4mAC2I5D8JM+uLOumVdv EuWscgnXzkpzUjE2CsfxSiUFm4OrKSSZm+S0sJslJA== X-Received: by 2002:a05:6902:1025:: with SMTP id x5mr2865453ybt.96.1612947330653; Wed, 10 Feb 2021 00:55:30 -0800 (PST) MIME-Version: 1.0 References: <20210205222644.2357303-1-saravanak@google.com> <47ca46aa-99f3-5203-8aa7-65c6443bd965@microchip.com> In-Reply-To: <47ca46aa-99f3-5203-8aa7-65c6443bd965@microchip.com> From: Saravana Kannan Date: Wed, 10 Feb 2021 00:54:54 -0800 Message-ID: Subject: Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving To: Tudor Ambarus Cc: Jonathan Corbet , Greg Kroah-Hartman , "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , "Brown, Len" , Len Brown , Pavel Machek , Michael Turquette , Stephen Boyd , Rob Herring , Frank Rowand , Marc Zyngier , Thomas Gleixner , Linux Doc Mailing List , LKML , Linux PM , linux-clk , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , ACPI Devel Maling List , Marek Szyprowski , Geert Uytterhoeven , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 10, 2021 at 12:19 AM wrote: > > Hi, Saravana, > > On 2/6/21 12:26 AM, Saravana Kannan wrote: > > There are a lot of devices/drivers where they never have a struct device > > created for them or the driver initializes the hardware without ever > > binding to the struct device. > > > > This series is intended to avoid any boot regressions due to such > > devices/drivers when fw_devlink=on and also address the handling of > > optional suppliers. > > > > Patch 1 and 2 addresses the issue of firmware nodes that look like > > they'll have struct devices created for them, but will never actually > > have struct devices added for them. For example, DT nodes with a > > compatible property that don't have devices added for them. > > > > Patch 3 and 4 allow for handling optional DT bindings. > > > > Patch 5 sets up a generic API to handle drivers that never bind with > > their devices. > > > > Patch 6 through 8 update different frameworks to use the new API. > > > > Thanks, > > Saravana > > > > Saravana Kannan (8): > > driver core: fw_devlink: Detect supplier devices that will never be > > added > > of: property: Don't add links to absent suppliers > > driver core: Add fw_devlink.strict kernel param > > of: property: Add fw_devlink support for optional properties > > driver core: fw_devlink: Handle suppliers that don't use driver core > > irqdomain: Mark fwnodes when their irqdomain is added/removed > > PM: domains: Mark fwnodes when their powerdomain is added/removed > > clk: Mark fwnodes when their clock provider is added/removed > > > > .../admin-guide/kernel-parameters.txt | 5 ++ > > drivers/base/core.c | 58 ++++++++++++++++++- > > drivers/base/power/domain.c | 2 + > > drivers/clk/clk.c | 3 + > > drivers/of/property.c | 16 +++-- > > include/linux/fwnode.h | 20 ++++++- > > kernel/irq/irqdomain.c | 2 + > > 7 files changed, 98 insertions(+), 8 deletions(-) > > > > Even with this patch set applied, sama5d2_xplained can not boot. > Patch at [1] makes sama5d2_xplained boot again. Stephen applied it > to clk-next. I'm glad you won't actually have any boot issues in 5.12, but the fact you need [1] with this series doesn't make a lot of sense to me because: 1. The FWNODE_FLAG_INITIALIZED flag will be set for the clock fwnode in question way before any consumer devices are added. 2. Any consumer device added after (1) will stop trying to link to the clock device. Are you somehow adding a consumer to the clock fwnode before (1)? Can you try this patch without your clk fix? I was trying to avoid looping through a list, but looks like your case might somehow need it? -Saravana +++ b/drivers/base/core.c @@ -943,6 +943,31 @@ static void device_links_missing_supplier(struct device *dev) } } +static int fw_devlink_check_suppliers(struct device *dev) +{ + struct fwnode_link *link; + int ret = 0; + + if (!dev->fwnode ||fw_devlink_is_permissive()) + return 0; + + /* + * Device waiting for supplier to become available is not allowed to + * probe. + */ + mutex_lock(&fwnode_link_lock); + list_for_each_entry(link, &dev->fwnode->suppliers, c_hook) { + if (link->supplier->flags & FWNODE_FLAG_INITIALIZED) + continue; + + ret = -EPROBE_DEFER; + break; + } + mutex_unlock(&fwnode_link_lock); + + return ret; +} + /** * device_links_check_suppliers - Check presence of supplier drivers. * @dev: Consumer device. @@ -964,21 +989,13 @@ int device_links_check_suppliers(struct device *dev) struct device_link *link; int ret = 0; - /* - * Device waiting for supplier to become available is not allowed to - * probe. - */ - mutex_lock(&fwnode_link_lock); - if (dev->fwnode && !list_empty(&dev->fwnode->suppliers) && - !fw_devlink_is_permissive()) { + if (fw_devlink_check_suppliers(dev)) { dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n", list_first_entry(&dev->fwnode->suppliers, struct fwnode_link, c_hook)->supplier); - mutex_unlock(&fwnode_link_lock); return -EPROBE_DEFER; } - mutex_unlock(&fwnode_link_lock); device_links_write_lock(); > > Cheers, > ta > > [1] https://lore.kernel.org/lkml/20210203154332.470587-1-tudor.ambarus@microchip.com/