Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Mon, 23 Oct 2023 14:59:02 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Florian Eckert <fe@dev.tdt.de>
Cc:     Eckert.Florian@googlemail.com, jirislaby@kernel.org, pavel@ucw.cz,
        lee@kernel.org, kabel@kernel.org, u.kleine-koenig@pengutronix.de,
        m.brock@vanmierlo.com, linux-kernel@vger.kernel.org,
        linux-serial@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v5 2/2] leds: ledtrig-tty: add new line mode evaluation
Message-ID: <2023102333-skewer-reclining-8d04@gregkh>
References: <20231023094205.2706812-1-fe@dev.tdt.de>
 <20231023094205.2706812-3-fe@dev.tdt.de>
 <2023102341-jogger-matching-dded@gregkh>
 <7e8860574413505c314bdfd0f3e10188@dev.tdt.de>
 <2023102320-princess-issuing-be13@gregkh>
 <c4398f09d5a07672ad77f2100ccae0f4@dev.tdt.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c4398f09d5a07672ad77f2100ccae0f4@dev.tdt.de>
Precedence: bulk

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