[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210422143945.n5gqkeh2y2jm6ece@pengutronix.de>
Date: Thu, 22 Apr 2021 16:39:45 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Juergen Borleis <jbe@...gutronix.de>, kernel@...gutronix.de,
linux-doc@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
linux-leds@...r.kernel.org
Subject: Re: [PATCH] leds: trigger/tty: feature data direction
Hello Greg,
On Thu, Apr 22, 2021 at 10:05:28AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 22, 2021 at 09:47:02AM +0200, Juergen Borleis wrote:
> > +static ssize_t dirfilter_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
> > +
> > + if (trigger_data->indirection)
> > + return (ssize_t)sprintf(buf, "in\n");
> > + if (trigger_data->outdirection)
> > + return (ssize_t)sprintf(buf, "out\n");
> > + return (ssize_t)sprintf(buf, "inout\n");
>
> sysfs_emit() please.
>
> And you are adding new sysfs files, that requires an update to
> Documentation/ABI/ please do so.
I agree to these two suggestions.
> But why are you adding random new sysfs values to a class device? That
> feels really wrong.
This is quite usual for triggers and there is IMHO no way around this.
And it is also save as led_trigger_set() emits an uevent after a trigger
was activated.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists