public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	Richard Gong <richard.gong@linux.intel.com>,
	Romain Izard <romain.izard.pro@gmail.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mans Rullgard <mans@mansr.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH 01/11] Platform: add a dev_groups pointer to struct platform_driver
Date: Thu, 4 Jul 2019 11:32:00 +0200	[thread overview]
Message-ID: <20190704093200.GM13424@localhost> (raw)
In-Reply-To: <20190704084617.3602-2-gregkh@linuxfoundation.org>

On Thu, Jul 04, 2019 at 10:46:07AM +0200, Greg Kroah-Hartman wrote:
> Platform drivers like to add sysfs groups to their device, but right now
> they have to do it "by hand".  The driver core should handle this for
> them, but there is no way to get to the bus-default attribute groups as
> all platform devices are "special and unique" one-off drivers/devices.
> 
> To combat this, add a dev_groups pointer to platform_driver which allows
> a platform driver to set up a list of default attributes that will be
> properly created and removed by the platform driver core when a probe()
> function is successful and removed right before the device is unbound.
> 
> Cc: Richard Gong <richard.gong@linux.intel.com>
> Cc: Romain Izard <romain.izard.pro@gmail.com>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mans Rullgard <mans@mansr.com>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/base/platform.c         | 40 +++++++++++++++++++++------------
>  include/linux/platform_device.h |  1 +
>  2 files changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 713903290385..d81fcd435b52 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -598,6 +598,21 @@ struct platform_device *platform_device_register_full(
>  }
>  EXPORT_SYMBOL_GPL(platform_device_register_full);
>  
> +static int platform_drv_remove(struct device *_dev)
> +{
> +	struct platform_driver *drv = to_platform_driver(_dev->driver);
> +	struct platform_device *dev = to_platform_device(_dev);
> +	int ret = 0;
> +
> +	if (drv->remove)
> +		ret = drv->remove(dev);
> +	if (drv->dev_groups)
> +		device_remove_groups(_dev, drv->dev_groups);

Shouldn't you remove the groups before calling driver remove(), which
could be releasing resources used by the attribute implementations?

This would also be the reverse of how what you do at probe.

> +	dev_pm_domain_detach(_dev, true);
> +
> +	return ret;
> +}
> +
>  static int platform_drv_probe(struct device *_dev)
>  {
>  	struct platform_driver *drv = to_platform_driver(_dev->driver);
> @@ -614,8 +629,18 @@ static int platform_drv_probe(struct device *_dev)
>  
>  	if (drv->probe) {
>  		ret = drv->probe(dev);
> -		if (ret)
> +		if (ret) {
>  			dev_pm_domain_detach(_dev, true);
> +			goto out;
> +		}
> +	}
> +	if (drv->dev_groups) {
> +		ret = device_add_groups(_dev, drv->dev_groups);
> +		if (ret) {
> +			platform_drv_remove(_dev);

This would lead to device_remove_groups() being called for the never
added attribute groups. Looks like that may trigger a warning in the
sysfs code judging from a quick look.

> +			return ret;
> +		}
> +		kobject_uevent(&_dev->kobj, KOBJ_CHANGE);
>  	}

Johan

  reply	other threads:[~2019-07-04  9:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  8:46 [PATCH 00/11] Platform drivers, provide a way to add sysfs groups easily Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 01/11] Platform: add a dev_groups pointer to struct platform_driver Greg Kroah-Hartman
2019-07-04  9:32   ` Johan Hovold [this message]
2019-07-04 10:43     ` Greg Kroah-Hartman
2019-07-04 12:11       ` [PATCH 01/12 v2] " Greg Kroah-Hartman
2019-07-04 21:17         ` Dmitry Torokhov
2019-07-06  8:32           ` Greg Kroah-Hartman
2019-07-06 17:04             ` Dmitry Torokhov
2019-07-06 17:19               ` Greg Kroah-Hartman
2019-07-06 17:39                 ` Dmitry Torokhov
2019-07-19 11:52                   ` Greg Kroah-Hartman
2019-07-20  4:38                     ` Dmitry Torokhov
2019-07-25 13:44                       ` Greg Kroah-Hartman
2019-07-25 19:02                         ` Richard Gong
2019-07-25 19:04                           ` Greg Kroah-Hartman
2019-07-25 19:13                             ` Dmitry Torokhov
2019-07-25 19:18                           ` Dmitry Torokhov
2019-07-04  8:46 ` [PATCH 02/11] uio: uio_fsl_elbc_gpcm: convert platform driver to use dev_groups Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 03/11] serial: sh-sci: use driver core functions, not sysfs ones Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 04/11] firmware: arm_scpi: convert platform driver to use dev_groups Greg Kroah-Hartman
2019-07-04  9:10   ` Sudeep Holla
2019-07-31 12:28     ` Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 05/11] olpc: x01: " Greg Kroah-Hartman
2019-07-04 13:28   ` Andy Shevchenko
2019-07-04  8:46 ` [PATCH 06/11] platform: x86: hp-wmi: " Greg Kroah-Hartman
2019-07-04 13:29   ` Andy Shevchenko
2019-07-04  8:46 ` [PATCH 07/11] video: fbdev: wm8505fb: " Greg Kroah-Hartman
2019-07-04 13:29   ` Andy Shevchenko
2019-07-04 14:25     ` Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 08/11] video: fbdev: w100fb: " Greg Kroah-Hartman
2019-07-05 15:01   ` Bartlomiej Zolnierkiewicz
2019-07-04  8:46 ` [PATCH 09/11] video: fbdev: sm501fb: " Greg Kroah-Hartman
2019-07-05 15:01   ` Bartlomiej Zolnierkiewicz
2019-07-04  8:46 ` [PATCH 10/11] input: keyboard: gpio_keys: " Greg Kroah-Hartman
2019-07-04  8:46 ` [PATCH 11/11] input: axp20x-pek: " Greg Kroah-Hartman
2019-07-04 14:26 ` [PATCH 07/11] video: fbdev: wm8505fb: " Greg Kroah-Hartman
2019-07-05 15:00   ` Bartlomiej Zolnierkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190704093200.GM13424@localhost \
    --to=johan@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=richard.gong@linux.intel.com \
    --cc=romain.izard.pro@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox