Re: [PATCH RFC 0/2] next round for an uart led trigger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Greg,

On Wed, Nov 07, 2018 at 10:29:21AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 06, 2018 at 10:37:37PM +0100, Uwe Kleine-König wrote:
> > this is the next round of a led trigger for an UART. Instead of adding
> > callbacks to serial_core I took an approach similar to the netdev
> > trigger: A work thread checks the statistics of the device and if
> > something happened since the last round the LED is flashed.
> > 
> > This is an early prototype that has broken locking. Also in the long run
> > I want to add some "filters" to the trigger for example to trigger only
> > on RX or TX.
> > 
> > Do you (also) think this is a better approach then in the former
> > discussions?
> > 
> > I'm not yet sure how to get the locking right. After the trigger driver
> > got a pointer to the uart_ports structure the port must not go away
> > until the statistics are checked. If you have an idea here that would
> > be great.
> 
> How does the networking core handle this type of interaction?  Can't you
> solve this the same way they do?

the netdev trigger keeps the device active using dev_hold/dev_put.

> And yes, this seems like a much better way to handle this, good idea.

\o/

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux