Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1849551pxb; Fri, 5 Mar 2021 00:48:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwz83z9ju9Ye07QDXHW+ZmKA3CLS2mHCYghgHKgR+znTaM1x+xpT5Ut9Lnf4cdZJV0sG68v X-Received: by 2002:a5d:9506:: with SMTP id d6mr7261626iom.37.1614934115081; Fri, 05 Mar 2021 00:48:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614934115; cv=none; d=google.com; s=arc-20160816; b=ld6ERcAD6H3Lizxvofr7VTC3E5nwW2GYQnBGu1fcbNPpsRX6B6PbISA4n5+sceS1tW 2b20PqtVw0y+d2cChqLq9Yg3adaXx5cF2iShMWka4c5/8gYB3HejbsKSEv0tQUOt+MGR 6uX7BlJfOmkhJZkR7YlRbdwzLkHlEdk824/WwAEj8KM4jIHbo07rB/YGE3Lo1jv+zs/D 1jXcZBcLapoq3DlUY95rCbwGxeiauBRkdRgzohgxEiNXEC1GE7Ckx5Upprgn/8AJdv7+ EkZqLsdOl7NOkqAA+tHDjD5NF6B0J8sCptyGdt7QVjHhBaRhgr/lJWMvHSkRbFBfqD+J dlyg== 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=5iA4x57cYD26M9mH9ZJl/HuREPakbn8+6uPhwu8dScQ=; b=Azwaebengsyj+is7/nrmW+zi/2hCUA411QXZeZgzH26Hra0bcbpr27baLc6h4hFVlV pd7oiAKH3fQEDS37HL0IdGsYubcGs7AZW3KVLa0E8+yUOTzRqfviDVaDigmxfWeC1Sau ZnQIyjvLHR99zC1cvtLbORMyxQv+4DN/xMYqeS0QQhJim6ln5lw6gnWQ3FFtdzlkRUpO jG8rNNdVjcY1XoF+vDiRd1lMGKd/xXvtWGHREU92KExF7fA/S/R8Q1dduz5HGnKYJw7W ueocU5aU+1gOGBjSySzjhqGkSb7OkUaZQ2z6JgDcEQihXvDSp6twTbkkNMcLOgRPRyjS hu7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=NfLSGdKW; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e8si1811407ilc.89.2021.03.05.00.48.21; Fri, 05 Mar 2021 00:48:35 -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=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=NfLSGdKW; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229578AbhCEIqW (ORCPT + 99 others); Fri, 5 Mar 2021 03:46:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbhCEIpx (ORCPT ); Fri, 5 Mar 2021 03:45:53 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77AAFC06175F for ; Fri, 5 Mar 2021 00:45:53 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id mj10so1898709ejb.5 for ; Fri, 05 Mar 2021 00:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iA4x57cYD26M9mH9ZJl/HuREPakbn8+6uPhwu8dScQ=; b=NfLSGdKWY4SW5FR5f1IF46zHLQNEnhdkLS+i/UTCwbQJl3iejMao+y0vnNga2Rm51m UPhwK0pUNjGXenfpV40qgmpkqDIDWwM8PHXixt/Ix6mGuGMM0thPNB0LDKi87aqZh6hE xI0tOylhI5e87UfYhA7fkkP4ZGOSHgs1APTcpwVICgS67QeqmMWOg50ZFVFcsdfcIMQa YFeteLio3B6FM0SAoP/p/UOpn+WtV1jZ8v8fqI49wq+yMcgIoZ9mn38ZcpKf/1TDBtyi NTWzqTeDX7eHn2ihLG7oChALd4H/OyrOcDSldnMC3lXH7Po0IN9YqR2c/8Cf8p7JTN7i Qpxg== 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=5iA4x57cYD26M9mH9ZJl/HuREPakbn8+6uPhwu8dScQ=; b=QUyfogbV9TV6+irPuWlnAB2dezU877JIt6inA1cR8vFu7y1CGaQwTpjSwyethA8TnV hR1MRHfNmK3uDsnHzSRQ2TDVNiDqZSXv9c7BSxP6trfjyALv1Dpw9gQdcuUehi3UFm0s q93yfVCek7JFvYIDngo3jWj+JEHm9359Jqm5ER7mHapcgoXmWqE8R1826TDnQTBAinHV RQqtSmiUSb76eYkOwRQ+uZ54vk3Njmob5eNpvI3ATHlxB5JQ5OOk5sGTqy5S2sWnYIHl QDnr5nLh+9uX1jPgStMNI9R3N6aneexg5mp4ONGv9/klUezyOHRyVc2xySxE4evNss8J duZA== X-Gm-Message-State: AOAM533CgEoTOCF4P53Z6oQpTopgQ31WWR5UfXQDWNEOeXgITH7hn/BC bc+4on923n7UKFeOM/J8mFnR15j7huhijtnVLvqfNA== X-Received: by 2002:a17:906:d938:: with SMTP id rn24mr1425523ejb.87.1614933952198; Fri, 05 Mar 2021 00:45:52 -0800 (PST) MIME-Version: 1.0 References: <20210304102452.21726-1-brgl@bgdev.pl> <20210304102452.21726-9-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Fri, 5 Mar 2021 09:45:41 +0100 Message-ID: Subject: Re: [PATCH v2 08/12] drivers: export device_is_bound() To: Greg KH Cc: Geert Uytterhoeven , Joel Becker , Christoph Hellwig , Shuah Khan , Linus Walleij , Andy Shevchenko , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Kent Gibson , Jonathan Corbet , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , "open list:DOCUMENTATION" , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 5, 2021 at 9:34 AM Greg KH wrote: > > On Fri, Mar 05, 2021 at 09:18:30AM +0100, Geert Uytterhoeven wrote: > > CC Greg > > > > On Thu, Mar 4, 2021 at 11:30 AM Bartosz Golaszewski wrote: > > > > > > From: Bartosz Golaszewski > > > > > > Export the symbol for device_is_bound() so that we can use it in gpio-sim > > > to check if the simulated GPIO chip is bound before fetching its driver > > > data from configfs callbacks in order to retrieve the name of the GPIO > > > chip device. > > > > > > Signed-off-by: Bartosz Golaszewski > > > --- > > > drivers/base/dd.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > > > index 9179825ff646..c62c02e3490a 100644 > > > --- a/drivers/base/dd.c > > > +++ b/drivers/base/dd.c > > > @@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev) > > > { > > > return dev->p && klist_node_attached(&dev->p->knode_driver); > > > } > > > +EXPORT_SYMBOL_GPL(device_is_bound); > > No. Please no. Why is this needed? Feels like someone is doing > something really wrong... > > NACK. > I should have Cc'ed you the entire series, my bad. This is the patch that uses this change - it's a new, improved testing module for GPIO using configfs & sysfs as you (I think) suggested a while ago: https://lkml.org/lkml/2021/3/4/355 The story goes like this: committing the configfs item registers a platform device. As far as I understand - there's no guarantee that the device will be bound to a driver before the commit callback (or more specifically platform_device_register_full() in this case) returns so the user may try to retrieve the name of the device immediately (normally user-space should wait for the associated uevent but nobody can force that) by doing: mv /sys/kernel/config/gpio-sim/pending/foo /sys/kernel/config/gpio-sim/live/ cat /sys/kernel/config/gpio-sim/live/foo/dev_name If the device is not bound at this point, we'll have a crash in the kernel as opposed to just returning -ENODEV. Please advise on how to handle it without device_is_bound(). Best Regards, Bartosz