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

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

 



On Wed, Nov 07, 2018 at 10:39:25AM +0100, Uwe Kleine-König wrote:
> 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.

Ok, and why will that same scheme not work here as well?

thanks,

greg k-h



[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