Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp2733558rwo; Thu, 3 Aug 2023 14:11:00 -0700 (PDT) X-Google-Smtp-Source: APBJJlFbtbm0gC8SVLe//qmnH3QCFrnpFLNM+J8z89tR01C+YrVmkGfEIIfTeIa8AX8nfjpM1oAL X-Received: by 2002:aa7:c0d4:0:b0:522:cc6c:e25e with SMTP id j20-20020aa7c0d4000000b00522cc6ce25emr8862540edp.3.1691097060104; Thu, 03 Aug 2023 14:11:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691097060; cv=none; d=google.com; s=arc-20160816; b=ZHrONLXOLTVo06CNz0Y7lRF8GGqr/nNemBlB4eETnJT47vB+se2kYQYVzX99XcyD2H zQD7Rb1GrgvvFpvqTGw3J2D40WbVQMyK3RRzjj73WRomUuYptR+2WaIHelKW3THKKCpK 74oNf4+9x7IaKpbjvEvnqBh/kx39whJ1FknFDIG/a6u+RoWOH19DcVc2zInqqOg3AYMi dT+eWMKfWPK7Pnqy6Q4zbhAWreKeAt+YGsKhmUljt5lnNbtqovUM/kCcWRNEB3+FxAwq MOk2ZnsAQ0tkp7WBwxTwctgIfuZqqeZa4hORbozYPlW0JQhnuNQ0ZMkptJM94MpUwBNI BEJQ== 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=rqLvNnIUzrROBT5rajV36LBK+ny6+l2//bZ787j+lX4=; fh=rqSh8cN1uN1lS1JFKRiazDfs85Tdo8G2P0UujK0LGHE=; b=iJYA92m1jzrmcBc7KK9GzUWIqPxOVaz8vrHMoC6sFL3uCf5DPeplx6YDz4WLfH1RYJ c4+kdiLgytphsWwFaPviOSUDqjHZVTf6xTU/CrafIQ/RTpU8+E6JatIkajev0JoyDA7u fUmV7qc9Y/S2K/spKcJq47Y649rxjv7PxYtXfkbLs9xNfsAkq/XYq5pUmCBpwtgazAYu 0x9gRTGtTeuMMwwo3njkCCZf0EoUlYFlB2Ypi6yCwp2U2Sstx4LyiVP9K2JaQfpHp5AR a1y3dVf2Awi3b+1+NvxnxRg9NG28LHqvXIHr2tufbv7xWx3dz3XzZHZI+BIDoDO5nVKL 5JDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=mhL62TV2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w15-20020a50fa8f000000b005231425d183si417892edr.216.2023.08.03.14.10.35; Thu, 03 Aug 2023 14:11:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=mhL62TV2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232243AbjHCUwu (ORCPT + 99 others); Thu, 3 Aug 2023 16:52:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjHCUwt (ORCPT ); Thu, 3 Aug 2023 16:52:49 -0400 X-Greylist: delayed 428 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 03 Aug 2023 13:52:47 PDT Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [71.19.156.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D826C11F for ; Thu, 3 Aug 2023 13:52:47 -0700 (PDT) Received: from hatter.bewilderbeest.net (63-228-114-1.tukw.qwest.net [63.228.114.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 3BAFE783; Thu, 3 Aug 2023 13:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1691095539; bh=rqLvNnIUzrROBT5rajV36LBK+ny6+l2//bZ787j+lX4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mhL62TV2yHCgtCLXCMNy6nG3wukcImfjmhjBbDWP+XreY0GCrVku3IgD5CDWFhLD0 8UZLOMEpHD7qYEBrZPyiqgbhjJVMDb/gxuye1Ab2pKaBHewkppUYFM3ag6mYPSVxUR x3/MqJ8tP9SjEdzdci9DKx+SL++vEGK1xU84Jo7k= Date: Thu, 3 Aug 2023 13:45:37 -0700 From: Zev Weiss To: Naresh Solanki Cc: Liam Girdwood , Mark Brown , linux-kernel@vger.kernel.org Subject: Re: [PATCH] regulator: userspace-consumer: Add regulator event support Message-ID: References: <20230803111225.107572-1-Naresh.Solanki@9elements.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20230803111225.107572-1-Naresh.Solanki@9elements.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 03, 2023 at 04:12:25AM PDT, Naresh Solanki wrote: >Add sysfs attribute to track regulator events received from regulator >notifier block handler. > Hi Naresh, Could you provide a bit more detail on how this is intended to be used? Some of the details (more below) seem a bit odd to me... >Signed-off-by: Naresh Solanki >--- > drivers/regulator/userspace-consumer.c | 52 +++++++++++++++++++++++++- > 1 file changed, 51 insertions(+), 1 deletion(-) > >diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/userspace-consumer.c >index 97f075ed68c9..a0b980022993 100644 >--- a/drivers/regulator/userspace-consumer.c >+++ b/drivers/regulator/userspace-consumer.c >@@ -29,6 +29,10 @@ struct userspace_consumer_data { > > int num_supplies; > struct regulator_bulk_data *supplies; >+ >+ struct kobject *kobj; >+ struct notifier_block nb; >+ unsigned long events; > }; > > static ssize_t name_show(struct device *dev, >@@ -89,12 +93,30 @@ static ssize_t state_store(struct device *dev, struct device_attribute *attr, > return count; > } > >+static DEFINE_MUTEX(events_lock); >+ >+static ssize_t events_show(struct device *dev, >+ struct device_attribute *attr, char *buf) >+{ >+ struct userspace_consumer_data *data = dev_get_drvdata(dev); >+ unsigned long e; >+ >+ mutex_lock(&events_lock); >+ e = data->events; >+ data->events = 0; ...particularly this bit -- a read operation on a read-only file (and especially one with 0644 permissions) having side-effects (clearing the value it accesses) seems on the face of it like fairly surprising behavior. Is this a pattern that's used elsewhere in any other sysfs files? >+ mutex_unlock(&events_lock); >+ >+ return sprintf(buf, "0x%lx\n", e); >+} >+ > static DEVICE_ATTR_RO(name); > static DEVICE_ATTR_RW(state); >+static DEVICE_ATTR_RO(events); New sysfs attributes should be documented in Documentation/ABI, which this appears to be missing. However, it looks like this would expose the values of all the REGULATOR_EVENT_* constants as a userspace-visible ABI -- is that something we really want to do? > > static struct attribute *attributes[] = { > &dev_attr_name.attr, > &dev_attr_state.attr, >+ &dev_attr_events.attr, > NULL, > }; > >@@ -115,12 +137,28 @@ static const struct attribute_group attr_group = { > .is_visible = attr_visible, > }; > >+static int regulator_userspace_notify(struct notifier_block *nb, >+ unsigned long event, >+ void *ignored) >+{ >+ struct userspace_consumer_data *data = >+ container_of(nb, struct userspace_consumer_data, nb); >+ >+ mutex_lock(&events_lock); >+ data->events |= event; >+ mutex_unlock(&events_lock); >+ Using a single global mutex (events_lock) to protect a single member of a per-device struct looks weird. Unless there's something subtle going on that I'm not seeing, it seems like the lock should be a member of the data struct instead of global, and since no blocking operations happen under it could it just be a spinlock? Or since it's just some simple updates to a single variable, why not just use an atomic_t and skip the lock entirely? >+ sysfs_notify(data->kobj, NULL, dev_attr_events.attr.name); >+ >+ return NOTIFY_OK; >+} >+ > static int regulator_userspace_consumer_probe(struct platform_device *pdev) > { > struct regulator_userspace_consumer_data tmpdata; > struct regulator_userspace_consumer_data *pdata; > struct userspace_consumer_data *drvdata; >- int ret; >+ int i, ret; > > pdata = dev_get_platdata(&pdev->dev); > if (!pdata) { >@@ -153,6 +191,7 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev) > drvdata->num_supplies = pdata->num_supplies; > drvdata->supplies = pdata->supplies; > drvdata->no_autoswitch = pdata->no_autoswitch; >+ drvdata->kobj = &pdev->dev.kobj; > > mutex_init(&drvdata->lock); > >@@ -186,6 +225,13 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev) > } > drvdata->enabled = !!ret; > >+ drvdata->nb.notifier_call = regulator_userspace_notify; >+ for (i = 0; i < drvdata->num_supplies; i++) { >+ ret = devm_regulator_register_notifier(drvdata->supplies[i].consumer, &drvdata->nb); >+ if (ret) >+ goto err_enable; >+ } >+ > return 0; > > err_enable: >@@ -197,6 +243,10 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev) > static int regulator_userspace_consumer_remove(struct platform_device *pdev) > { > struct userspace_consumer_data *data = platform_get_drvdata(pdev); >+ int i; >+ >+ for (i = 0; i < data->num_supplies; i++) >+ devm_regulator_unregister_notifier(data->supplies[i].consumer, &data->nb); > > sysfs_remove_group(&pdev->dev.kobj, &attr_group); > > >base-commit: 4fb53b2377c364e3753d6e293913b57dad68e98b >-- >2.41.0 >