Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1899778pxb; Fri, 5 Mar 2021 02:25:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJzno9O2nHcALYoWajxkMvZe9PFNN4jw9iGiGUmJBJd/YeqTbaDDxJrKcPUtHNUGeMD4Qa74 X-Received: by 2002:a05:6402:1342:: with SMTP id y2mr8525079edw.285.1614939953098; Fri, 05 Mar 2021 02:25:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614939953; cv=none; d=google.com; s=arc-20160816; b=Mu1CbjbR7Rzf0fmzlWZ6SUb89WIO2pxLLwNTYvk9RZDk6azPBD2XfS0sb6TnD0ymQ1 t+KoZ29wFLhBaOyj9zzMbvWBJ0PC4EQt+OyIVHAi6A5wQyjv7HwW51EGPMasdCQSeEdI HglQCnHk5A6TUM8JQtr2CD4ZyIp0eVnyK5KZzEyV2ErhMi+yRSVTNeCYG4Z8T8Up/7P0 6mCPblJ6VH01m32gMqzbj5wLj5NFrAUcYN0DbW8PAT854kYm4VAAPhRiY+sspBhxItkQ VkYCYjflvf9B/s3x3mJVww/bMl3VUbjyNhVw6ZGn31QT0/4vH7Jcgh+SrIRzWxCkM18i IewA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ePtRac8Um7qlPPzjWnxekvLPrkSHDxR92iaxSwvEt58=; b=nUoqmaAULKUaiAQmXVerLW27gwJxRIcozVfHdkpC4lym+x/rGJ0OXIlQTuYdfeNYyh ci5gEsG6w7tU7Q1468xhNXAESdf2+x7/GRJsbbI+XmsLdTY2slPu+7urPFVzP4eg8ZIh /8KwDGK8abCyDm35ES8raeo/iW/NtOOKZRYPyMBH/GHxCn0bGKXJFw7amRlCVCOdkXfJ s6u67/AV+bSkUfxcNGRppnBtAzybOU1WXEuh0wtVMB1CPMR/51V3aXi7bhbgLTlgQ5MT KHmS2zi3hbOihuGKbYo8VqxFSYunU6IC6SlI+jHQYgPStXS2JmXZiS5wBF1jXoh2njSE e0TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=EUZPPaY8; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ka21si1085014ejc.655.2021.03.05.02.25.30; Fri, 05 Mar 2021 02:25:53 -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=@linuxfoundation.org header.s=korg header.b=EUZPPaY8; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229672AbhCEKYe (ORCPT + 99 others); Fri, 5 Mar 2021 05:24:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:53148 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbhCEKYW (ORCPT ); Fri, 5 Mar 2021 05:24:22 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5400264F60; Fri, 5 Mar 2021 10:24:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614939862; bh=PCjZwGuPtDOERTWm9atWeueaPz+VUz9TVRiY7Wp08Dg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EUZPPaY8/R5c81/HQ+m3iptQLi8dqYaCdrEW5Yuz93V/ipep9LDQjcaRx5AT2dCTT s0tGyxJlVzYUu33EMKu0lAYrZtdPxCA6oU8gH5l9MtCcIcJWObEfNAhM0U+77UU36D GfgiY+zf8NgkSvMhGBi5wEHtNOJeGrbLm6ta8r0g= Date: Fri, 5 Mar 2021 11:24:18 +0100 From: Greg KH To: Bartosz Golaszewski Cc: Geert Uytterhoeven , Joel Becker , Christoph Hellwig , Shuah Khan , Linus Walleij , Andy Shevchenko , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Kent Gibson , Jonathan Corbet , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , "open list:DOCUMENTATION" , Bartosz Golaszewski Subject: Re: [PATCH v2 08/12] drivers: export device_is_bound() Message-ID: References: <20210304102452.21726-1-brgl@bgdev.pl> <20210304102452.21726-9-brgl@bgdev.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 05, 2021 at 10:16:10AM +0100, Bartosz Golaszewski wrote: > On Fri, Mar 5, 2021 at 9:55 AM Greg KH wrote: > > > > On Fri, Mar 05, 2021 at 09:45:41AM +0100, Bartosz Golaszewski wrote: > > > 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. > > > > Ick, no, stop there, that's not a "real" device, please do not abuse > > platform devices like that, you all know I hate this :( > > > > Use the virtbus code instead perhaps? > > > > I have no idea what virtbus is and grepping for it only returns three > hits in: ./drivers/pci/iov.c and it's a function argument. > > If it stands for virtual bus then for sure it sounds like the right > thing but I need to find more info on this. Sorry, wrong name, see Documentation/driver-api/auxiliary_bus.rst for the details. "virtbus" was what I think about it as that was my original name for it, but it eventually got merged with a different name. > > > 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. > > > > How will the kernel crash? What has created the dev_name sysfs file > > before it is possible to be read from? That feels like the root > > problem. > > > > It's not sysfs - it's in configfs. Each chip has a read-only configfs > attribute that returns the name of the device - I don't really have a > better idea to map the configfs items to devices that committing > creates. Same question, why are you exporting a configfs attribute that can not be read from? Only export it when your driver is bound to the device. thanks, greg k-h