linux-kernel - Re: [PATCH v5 2/2] leds: ledtrig-tty: add new line mode evaluation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 23 Oct 2023 15:19:03 +0200
From:   Florian Eckert <fe@....tdt.de>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Eckert.Florian@...glemail.com, jirislaby@...nel.org, pavel@....cz,
        lee@...nel.org, kabel@...nel.org, u.kleine-koenig@...gutronix.de,
        m.brock@...mierlo.com, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH v5 2/2] leds: ledtrig-tty: add new line mode evaluation



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