On Tue, Nov 06, 2018 at 10:37:37PM +0100, Uwe Kleine-König wrote: > Hello, > > 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? And yes, this seems like a much better way to handle this, good idea. thanks, greg k-h
