linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: jacek.anaszewski@gmail.com, pavel@ucw.cz,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 6/9] leds: multicolor: Introduce a multicolor class definition
Date: Wed, 18 Sep 2019 21:56:10 +0200	[thread overview]
Message-ID: <20190918195610.GC2020317@kroah.com> (raw)
In-Reply-To: <f5cf1fa4-c891-744c-6fa9-4b166b64f463@ti.com>

On Wed, Sep 18, 2019 at 12:09:12PM -0500, Dan Murphy wrote:
> Greg
> 
> <snip>
> 
> > +static int led_multicolor_init_color(struct led_classdev_mc_data *data,
> > +				     struct led_classdev_mc *mcled_cdev,
> > +				     int color_id, int color_index)
> > +{
> > +	struct led_classdev *led_cdev = mcled_cdev->led_cdev;
> > +	struct led_mc_color_entry *mc_priv;
> > +	int ret;
> > +
> > +	mc_priv = devm_kzalloc(led_cdev->dev, sizeof(*mc_priv), GFP_KERNEL);
> > +	if (!mc_priv)
> > +		return -ENOMEM;
> > +
> > +	mc_priv->led_color_id = color_id;
> > +	mc_priv->mcled_cdev = mcled_cdev;
> > +
> > +	led_color_group.name = led_colors[color_id];
> > +	ret = sysfs_create_group(data->color_kobj, &led_color_group);
> > +	if (ret)
> > +		return ret;
> > +
> > +	sysfs_attr_init(&mc_priv->intensity_attr.attr);
> > +	mc_priv->intensity_attr.attr.name = "intensity";
> > +	mc_priv->intensity_attr.attr.mode = 666;
> > +	mc_priv->intensity_attr.store = intensity_store;
> > +	mc_priv->intensity_attr.show = intensity_show;
> > +	ret = sysfs_add_file_to_group(data->color_kobj,
> > +				      &mc_priv->intensity_attr.attr,
> > +				      led_color_group.name);
> > +	if (ret)
> > +		return ret;
> > +
> > +	sysfs_attr_init(&mc_priv->max_intensity_attr.attr);
> > +	mc_priv->max_intensity_attr.attr.name = "max_intensity";
> > +	mc_priv->max_intensity_attr.attr.mode = 444;
> > +	mc_priv->max_intensity_attr.show = max_intensity_show;
> > +	ret = sysfs_add_file_to_group(data->color_kobj,
> > +				      &mc_priv->max_intensity_attr.attr,
> > +				      led_color_group.name);
> > +	if (ret)
> > +		goto err_out;
> > +
> > +	mc_priv->max_intensity = LED_FULL;
> > +	list_add_tail(&mc_priv->list, &data->color_list);
> > +
> > +err_out:
> > +	return ret;
> > +}
> > +
> > +static int led_multicolor_init_color_dir(struct led_classdev_mc_data *data,
> > +					 struct led_classdev_mc *mcled_cdev)
> > +{
> > +	struct led_classdev *led_cdev = mcled_cdev->led_cdev;
> > +	u32 color_id;
> > +	int ret;
> > +	int i, j = 0;
> > +
> > +	data->color_kobj = kobject_create_and_add("colors",
> > +						  &led_cdev->dev->kobj);
> 
> We need some guidance here on how to properly create sub directories more
> then 1 level deep.

Short answer, don't.

Long answer, use a 'struct device' but ONLY IF YOU KNOW WHAT YOU ARE
DOING!

Follow the short answer please.

> In short under the LED class device parent directory we want to create a
> directory called "colors".

Ok, that's simple.

> Under that directory we want to create a directory corresponding to the
> monochrome LED color.

Why?

> Under that directory we have the files to for intensity and max_intensity
> for the monochrome LED.

Why not just have colors/monochrome_intensity and
colors/monochrome_max_intensity as your files in the colors/ directory?

> We can use the LED class kobject to create the colors directory using the
> sysfs calls but the issue comes when creating the LED color directory.

Yes.

> We don't have a kobj for colors to associate those directories to. 

And you shouldn't :)

> The only API we see to use the kobject_create_and_add which then gives
> us the colors directory kobj.

Don't do that, you will break userspace code hard if you do that.

NEVER put a raw kobject after a 'struct device' in the sysfs tree if you
expect normal userspace libraries to be able to understand what is going
on.  That's why this is "hard", you are not supposed to be doing it.

> So the directory structure would look like this which is explained in this
> patch https://lore.kernel.org/patchwork/patch/1128444/
> 
> Directory Layout Example
> ========================
> root:/sys/class/leds/rgb:grouped_leds# ls -lR colors/
> colors/:
> drwxr-xr-x    2 root     root             0 Jun 28 20:21 blue
> rwxr-xr-x    2 root     root             0 Jun 28 20:21 green
> drwxr-xr-x    2 root     root             0 Jun 28 20:21 red
> 
> colors/blue:
> -rw-------    1 root     root          4096 Jun 28 20:21 intensity
> -r--------    1 root     root          4096 Jun 28 20:27 max_intensity
> +colors/green:
> -rw-------    1 root     root          4096 Jun 28 20:22 intensity
> -r--------    1 root     root          4096 Jun 28 20:27 max_intensity
> 
> colors/red:
> -rw-------    1 root     root          4096 Jun 28 20:21 intensity
> -r--------    1 root     root          4096 Jun 28 20:27 max_intensity


No, just add blue, green, red to the prefix of those files and all
should be fine.  Don't try to get fancy and use subdirs, that way lies
madness.

> I have reviewed your example code and read your blogs and papers on the
> subject but nothing really talks about sub-sub directories.

Because you shouldn't do it, I didn't think I had to describe everything
you should not do :)

> Now if this is a no-no in the kernel that is fine we can adjust but Jacek
> wanted to get your opinon/guidance on this topic.

Yes, don't do it.

did I say it enough times?  :)

thanks,

greg k-h

  reply	other threads:[~2019-09-18 19:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 17:59 [PATCH v6 1/9] leds: multicolor: Add sysfs interface definition Dan Murphy
2019-09-17 17:59 ` [PATCH v6 2/9] documention: leds: Add multicolor class documentation Dan Murphy
2019-09-17 17:59 ` [PATCH v6 3/9] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-09-17 17:59 ` [PATCH v6 4/9] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-09-17 17:59 ` [PATCH v6 5/9] " Dan Murphy
2019-09-17 17:59 ` [PATCH v6 6/9] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-09-18 17:09   ` Dan Murphy
2019-09-18 19:56     ` Greg KH [this message]
2019-09-18 21:27   ` Jacek Anaszewski
2019-09-19  1:07     ` Dan Murphy
2019-09-19 21:32       ` Jacek Anaszewski
2019-09-20 12:31         ` Dan Murphy
2019-09-17 17:59 ` [PATCH v6 7/9] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-09-17 17:59 ` [PATCH v6 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-09-17 17:59 ` [PATCH v6 9/9] leds: Update the lp55xx to use the multi color framework Dan Murphy

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=20190918195610.GC2020317@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).