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?) 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? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
