Hi Uwe,
On 05/15/2018 10:14 PM, Uwe Kleine-König wrote:
Hello Jacek,
On Mon, May 14, 2018 at 09:50:20PM +0200, Jacek Anaszewski wrote:
On 05/14/2018 08:24 PM, Uwe Kleine-König wrote:
Does the led core provide the needed stuff for this already today? If
yes, then I didn't understand that from your review comments so far. Is
there an example to understand how these parameters work?
There is no ready solution for tty, but it can be implemented with
not so big effort. I don't know what exactly Pavel had on mind,
but I myself see now, that the better approach would be a new
ledtrig-ttydev driver, that would expose three sysfs files: tty_id,
rx, tx. It would also expose the API like e.g.:
ttydev_trig_notify(int tty_id, bool rx)
Please see drivers/leds/trigger/ledtrig-netdev.c for an example of
a solution to the quite similar problem.
I looked into this driver and it does forbidden stuff. You must not call
device_create_file() for an already bound device. (@gregkh: Would it be
a good idea to issue a warning when device_create_file is called too
late, maybe only if CONFIG_DEBUG_KERNEL=y or CONFIG_DEBUG_SOMETHING?)
Many LED triggers create their specific sysfs files this way.
A sane approach to such trigger parameters would include putting a
const struct attribute_group **groups member into the struct
led_trigger and let led_trigger_register do the right thing with it.
Not sure what "the right thing" is here. Just adding the group
certainly is not. We'd somehow need a new kobject for this. @gregkh:
Maybe you can comment and point out the way to go here?
kobject_uevent_env() is called on led_cdev->dev->kobj from
led_trigger_set().
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
