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/ |
