Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1360851ybx; Tue, 5 Nov 2019 14:56:17 -0800 (PST) X-Google-Smtp-Source: APXvYqwp+ld16xzLS4DzIQt7IFRXsSEqJTWgfJyWmmQmERoOBz1JbxCeydJK5CaAx9v2A0HAb5/1 X-Received: by 2002:a05:6402:8cb:: with SMTP id d11mr4225208edz.303.1572994576895; Tue, 05 Nov 2019 14:56:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572994576; cv=none; d=google.com; s=arc-20160816; b=kk7A+HuReUJo2H9V8Dj8Xsxm9sDMuwG3pyzOZOBm89fzYLe9eP+n8dXt/sAHUbT5OY 74+3BWHkDxfg1BIaQgoZkvoKth3DTjFel5lIrhgdI6hlcLMKnu18e6W1sGCHEi5i/oRC WBCkzsbfESkS76E/Gin14v6W4oWcy2QUIZLt9wZ2QY29n9PvBx/Ot2Wfa9dr4ynsTGSl dT2HKQ+3+UumJlEnKsvXTy3quUfFOS57UFEg123QZ2EwDjWCfCIQ0A19lQs44wFD4CpG 3KnQZHRyywy77aWqyF5oIBD+DqT7RAWclnfHwm5jdMEvVfJknof9ohiUbLzbJuKkQnol pdww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ITot2P1/Oq1djB16oG4kp1TUvRDEYRsyk0+fdSTUYw4=; b=is4Yq7HLYJrQ1xgRKiVnzytVc3ZAZue2cbee5Ed5xczrGstLVjVizrs6KmoZh6Xxdn x9ADiSSiLrTLRGcCRF0RbZ8ShejvrS8HEUCKTDfa/6QotVtOhusxT8yvHo3zq+2HgLZH 2raAkIlD+iMKyDelHXhjPSvYVecNMxtzsk29Zr01zxYlMpreMnUN3E3u17KsMgXPVxAG +XDmeYy2XgHqnmeJVp92TYFlpqXolb99pq39p0169ahhkiXxPT8z96yQ2fQHlIHnJlHW jb0wWz47MJpXBaVdqAq0H+WgS0DyZLKYX/v6l7VSFrXo5LfRY5tf6ArPE/PjaJiIgzBy oQOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iHLJvOrK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id b15si14344728ejb.266.2019.11.05.14.55.53; Tue, 05 Nov 2019 14:56:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iHLJvOrK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1730486AbfKEWxA (ORCPT + 99 others); Tue, 5 Nov 2019 17:53:00 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:34097 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730292AbfKEWw7 (ORCPT ); Tue, 5 Nov 2019 17:52:59 -0500 Received: by mail-oi1-f195.google.com with SMTP id l202so19188730oig.1 for ; Tue, 05 Nov 2019 14:52:58 -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=ITot2P1/Oq1djB16oG4kp1TUvRDEYRsyk0+fdSTUYw4=; b=iHLJvOrKMmGplCdoVyX0r+Vex/KiHX7/2gzEkqUGtS9y1kL5yKWQyCpQLbuDDjC9Is 5TTkBC0jgHz5YkvBoVLZNIH7IYS1FN/nj0Ri77yYoHW0RUq6VDBbgb860xuZ2D566gHO jRvW49c1h4UyvoTIeITBnbXm1wQ3Mm8r0o2DNuoBShnqCcNpFhej58iGH3HAx+Eog3Ql xiFj5N3CuW7VIh48JxSTvl30/ZCtzh10Y5GKZu7VKZvehv1luDEh0MfJe0gMx7PTzcZy ZXAoO63WuczkBq1yJB+WPezvFII9eB/rDNWPzS3RklXRdMP30mo+PQRRWpMbyt72LoYA NDCA== 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=ITot2P1/Oq1djB16oG4kp1TUvRDEYRsyk0+fdSTUYw4=; b=fXFyLiP9WDHnwEoRFzkx0kq1AakF/LgKeZFWcEVoMSzoNggRX8qJkJSZXVrT6MB1Iy Zh1Kc7fkqG9WpO1BuOZj1U5WDHgXT9T695XpYA4X9K0uy8ZGRrffCrGh+2aVkPHpQuRy yIFyy5XNtPj1cPueVuMverkHW3s85EDwO0ojFR03Pong0R70PZ0WVewfYwK/7xcpzFdC MpaXy7CkR71SGYKlNMtjSoTbzwfaL6AUVFK9AtZ2MbXI7rXT027PZHW0cYcvtGgVYTf4 8zX+2gZKqrt+hKYyK5TA17IC1hAuhwp7IWXyqCeqosHyggzmW2dzjlLCJ3fsPXou2ZaU /mPw== X-Gm-Message-State: APjAAAVZO7S572RRWGhrgCuGwMSXYxq7rvuyPBaJWOXcg34XeeuVSsxS uaXsHzXU5eBzqGrgKGy4CAb8AIRnF2yht5RBro39Sw== X-Received: by 2002:aca:d558:: with SMTP id m85mr1203360oig.43.1572994377809; Tue, 05 Nov 2019 14:52:57 -0800 (PST) MIME-Version: 1.0 References: <20191028220027.251605-1-saravanak@google.com> <20191028220027.251605-4-saravanak@google.com> <7640808.4Pc6YCm0Y9@kreacher> In-Reply-To: <7640808.4Pc6YCm0Y9@kreacher> From: Saravana Kannan Date: Tue, 5 Nov 2019 14:52:21 -0800 Message-ID: Subject: Re: [PATCH v1 3/5] driver core: Allow fwnode_operations.add_links to differentiate errors To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Rob Herring , Frank Rowand , Len Brown , Android Kernel Team , LKML , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-acpi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, Thanks for the review. On Tue, Nov 5, 2019 at 2:43 PM Rafael J. Wysocki wrote: > > On Monday, October 28, 2019 11:00:24 PM CET Saravana Kannan wrote: > > When add_links() still has suppliers that it needs to link to in the > > future, this patch allows it to differentiate between suppliers that are > > needed for probing vs suppliers that are needed for sync_state() > > correctness. > > I guess you mean that it will return different error codes in the different > cases. Yes. > > > Signed-off-by: Saravana Kannan > > --- > > drivers/base/core.c | 12 ++++++++---- > > include/linux/fwnode.h | 13 +++++++++---- > > 2 files changed, 17 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > index 48cd43a91ce6..e6d3e6d485da 100644 > > --- a/drivers/base/core.c > > +++ b/drivers/base/core.c > > @@ -2297,7 +2297,7 @@ int device_add(struct device *dev) > > struct device *parent; > > struct kobject *kobj; > > struct class_interface *class_intf; > > - int error = -EINVAL; > > + int error = -EINVAL, fw_ret; > > struct kobject *glue_dir = NULL; > > > > dev = get_device(dev); > > @@ -2413,9 +2413,13 @@ int device_add(struct device *dev) > > */ > > device_link_add_missing_supplier_links(); > > > > - if (fwnode_has_op(dev->fwnode, add_links) > > - && fwnode_call_int_op(dev->fwnode, add_links, dev)) > > - device_link_wait_for_mandatory_supplier(dev, true); > > + if (fwnode_has_op(dev->fwnode, add_links)) { > > fw_ret can be defined here and I'd just call it "ret". I thought that style of variable declaration is frowned up in the kernel coding style. > > > + fw_ret = fwnode_call_int_op(dev->fwnode, add_links, dev); > > + if (fw_ret == -ENODEV) > > + device_link_wait_for_mandatory_supplier(dev); > > + else if (fw_ret) > > + device_link_wait_for_optional_supplier(dev); > > + } > > > > bus_probe_device(dev); > > if (parent) > > diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h > > index 25bb81f8ded8..a19134eae5a5 100644 > > --- a/include/linux/fwnode.h > > +++ b/include/linux/fwnode.h > > @@ -96,10 +96,15 @@ struct fwnode_reference_args { > > * available suppliers. > > * > > * Return 0 if device links have been successfully created to all > > - * the suppliers of this device or if the supplier information is > > - * not known. Return an error if and only if the supplier > > - * information is known but some of the suppliers are not yet > > - * available to create device links to. > > + * the suppliers this device needs to create device links to or if > > + * the supplier information is not known. > > "the known suppliers of this device or if the supplier information is not known." "suppliers it needs to create device links to" is a subset of known suppliers. There's no requirement that fw needs to create links to ALL known suppliers. Just a minor distinction. > > + * > > + * Return -ENODEV if and only if the suppliers needed for probing > > + * the device are not yet available to create device links to. > > It would be more precise to say something like this: > > "Return -ENODEV if an attempt to create a device link to one of the device's > suppliers needed for probing it fails." "attempt to create a device link to one of the device's suppliers needed for probing it fails" to me means device_link_add() fails. But I'm trying to say that it should return an error if the struct device isn't even there yet. > > + * > > + * Return -EAGAIN if there are suppliers that need to be linked to > > + * that are not yet available but none of those suppliers are > > + * necessary for probing this device. > > "Return -EAGAIN if attempts to create device links to some of the device's > suppliers have failed, but those suppliers are not necessary for probing the > device." Same comment as before. The distinction I'm making here is that -EAGAIN is needed when the struct device itself isn't there. Btw, Greg already pulled these into driver-core-next. Let me know if you want me to send a delta patch to fix any of these comments. Thanks, Saravana