On 2023-10-23 14:59, Greg KH wrote:
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?
No, this could not be configured before. It always flashed as
soon as data went through the configured tty. It couldn't even
be switched off, only if I change the tty interface via sysfs
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.
Thank you for your review. I will incorporate your comments and split
the changes.
:+1:
---
Florian
