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
