Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1865110pxb; Fri, 5 Mar 2021 01:18:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJwbW34SwAYJMuzGqHI8xf1Q87oTJzwXUjo3hD0PrGp5ZeWZOXNk98Wjy7zsmH0okhz14ZrH X-Received: by 2002:a05:6602:2d04:: with SMTP id c4mr7593998iow.182.1614935885060; Fri, 05 Mar 2021 01:18:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614935885; cv=none; d=google.com; s=arc-20160816; b=pcLeS9UHOoDpCORgxfz3GjtfGOkWh4AQbWiUv1+PiefJZCPtJtn+SeQ3Wo1MwYsEcM 0CKxhIiRrnPvwWKbVC0qANDqy1cDshY+h7FgsjC2EHLI+RrvHECs2GBMR+1u22Lg0xgt oTC4TS7RWcvfLlMA3XGB/v5hoAwNBuRme56vR7SZn7zjkK2GJz2kyN9hoG13iVlG+hn/ Kv+cGZTa1EZ2XlZcB7JF1/MZjgBUVXjVHUriNsYRvtIt+VsfHZHJ+t6VHVS91lxzt/Y+ uGGCDfq5b8nDrCui1J58bXyofM74+mibNEvS2Bau8RcOx82qY1bGcyIMy+VFSmP4w6VA pAwQ== 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=xIBDWNNi8cOFiM8+evn3aAlmPQp0YRKNZPxj0/XqUWQ=; b=Skc7cbVtQVpL5AKoJRY0fAG0yiZa/RjsiBQMCGQDuR/tIxf+5orFi6XGmPUNt+X+mD ACJ+nCtXFO59tKhwGm+LDiF+yiGV3Z41OkmuJ6lhbWq1QSBIE5wkfQpQB7cnAn+o7Yeb aCBVG8VPjHwRldsN66LueMTgE5EdQbUukM4hJPJaks4wk14oRKDS1nbyAD5ASTZHMJnr RLckyTN9Z/jz71PuROb5o2ZtWfUchv38He4828jDNBvatbNsyhBiRap+lq/yB1+xk6zE ZdZr0qgf6LdStJTEbHoig+IpiwWD5aLeaucEGkkKIsUFbmRcZMmWjkxyjHVxydWCOEIy vCxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=u4Jyn3Q8; 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 i4si2222454iov.52.2021.03.05.01.17.49; Fri, 05 Mar 2021 01:18:05 -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=u4Jyn3Q8; 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 S229758AbhCEJQy (ORCPT + 99 others); Fri, 5 Mar 2021 04:16:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229592AbhCEJQX (ORCPT ); Fri, 5 Mar 2021 04:16:23 -0500 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29772C061574 for ; Fri, 5 Mar 2021 01:16:22 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id w9so1537778edt.13 for ; Fri, 05 Mar 2021 01:16:22 -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=xIBDWNNi8cOFiM8+evn3aAlmPQp0YRKNZPxj0/XqUWQ=; b=u4Jyn3Q8Pea4kIqitbrUxq9fdmX4drucuJlXzg8S7ph189frPo2kVhUymrtzX5OdAR aAqHuyC22KmTKQUB/uHq6J2eeMU+s/E5bg87cjyv76PXYyxdQ0G7SJ3puqj6TBkwME7y 6EpZRyomx+Bc6A7vI4NUJeHN5rDeHXCbqJmS4xnDiJqZIeTJEY1cI+XrTvR7pypf7cnj pNyFdrZrjjszeNDLuG9alPKk+c1tjMEfzjfhSqYvsaTC/RxuzjiKvQNq/lrfDqlAkQNT jGyXKCLuEDbv0EQwlWUbZicRiYnh8fvsF/tLy2s3Hy9Y0tlf+MusWoVKJx7A9tjFrgoC JNyQ== 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=xIBDWNNi8cOFiM8+evn3aAlmPQp0YRKNZPxj0/XqUWQ=; b=qLJ9iWfopOTZFwa4NvGuhdYT5/mpdb1FYiEN05FG/+iN6rbfMpTuldLoudi3O8cQqC MrofdEf3UPNi95pp6mfanNtHctw/+RXIe8MqH1Vu1tsp+LbvsgyWir95OADYYhcYEjQc nJ4yBCa6H2eThSIo0hYqnIyFkrF4zvxvnnh5AUiZf5FdKL/mi6FG3T0iS5xdZtzRyJeY e3jiPDhsB+QazVI3ucw7gY7jbmEn3AgLGtzx5NpRMW4wGJa2LP3fSthiMlDzfiHjvzct f7GtA00iY9NgRnc2Gn/JEOcYb60RPEADlLbUOXcA8mca4uQ6zNaPXx2eafBv/vfSpM24 fW3w== X-Gm-Message-State: AOAM530dxuon6UNeKE3bgpEow5g1foC03ynVBkS71uM5mXAMKAyMeVtE /wONB/t9jQfSIwHkCFHUS+w82kBN853xM3Ga7zS5Ow== X-Received: by 2002:a05:6402:17d6:: with SMTP id s22mr8257787edy.232.1614935780916; Fri, 05 Mar 2021 01:16:20 -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 10:16:10 +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: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. > > 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. > > Please advise on how to handle it without device_is_bound(). > > Please do not create sysfs files before they can be read from :) > Don't worry, I don't. Bartosz