On Mon, Oct 23, 2023 at 02:45:55PM +0200, Florian Eckert wrote: > > > On 2023-10-23 14:27, Greg KH wrote: > > On Mon, Oct 23, 2023 at 02:15:55PM +0200, Florian Eckert wrote: > > > > Again, I thought we had rx/tx already? If not, how was that controlled > > > > today? > > > > > > It could not be controlled! The LED flashed when data where > > > transferred. > > > This was the only function that the trigger supported. > > > > Ok, then maybe this needs to be a bit longer of a series. One that does > > the "tx/rx" feature, as that is needed today, and will be the more > > complex one, and then one-per-line-setting that you want to apply. > > > > That should make it much easier to review overall, right? > > Sorry for asking, but why should I split the change. > What is the added value? But if it is necessary, then I will do it. > > Before my change, the trigger could not be configured. > The LED always flashed when data was transferred. But you could configure that, right? on/off, correct? And now you are splitting this out into different "options", which are all different. > Now I can configure for which tty event the LED should flash or be on/off. Great. > So that the trigger behaves the same as before (flash on rx/tx > transmission), > I set the rx/tx bits in the function ledtrig_tty_activate() with the > following code. Nothing changes for the user of the trigger. > > /* Enable default rx/tx LED blink */ > set_bit(TRIGGER_TTY_TX, &trigger_data->ttytrigger); > set_bit(TRIGGER_TTY_RX, &trigger_data->ttytrigger); I agree, but now you are splitting this up into a much finer grained feature. Anyway, just a thought, I'll defer to the LED maintainers here as to how they want to see this, I thought it would actually be easier this way, maybe not, your call. thanks, greg k-h
