On Mon, 2021-09-27 at 17:18 +0000, Sebastian Andrzej Siewior wrote: > On 2021-09-27 17:44:51 [+0200], Pavel Machek wrote: > > > > Would you mind reading and responding to the rest of the email? > > The patch you mentioned, > https://https://lkml.kernel.org/r/.kernel.org/all/20210915181601.99a68f5718be.I1a28b342d2d52cdeeeb81ecd6020c25cbf1dbfc0@changeid/ > > would remove the lock from led_trigger_event(). > Are there any guarantees how many callbacks maybe invoked and what kind > of locks may be acquired? In a way, the point of my patch is that after it we don't have to *care* what locking happens in the callbacks. The problem in our driver was that we did a spinlock without disabling IRQs there in the callback, and that interacts badly with the rwlock in the LED subsystem. > Leaving kworker usage aside there are still things like spinlock_t usage > in input_leds_brightness_set(), nic78bx_brightness_set() (from a quick > grep) which have the same problems. Looks like *everything* (that can work on ARM) and uses a spinlock would have this problem? My patch doesn't address that at all. In fact, like I said above, the entire point of the patch is to remove restrictions on what the locking in the underlying LED driver can be. johannes
