Tom Zoerner <tomzo@xxxxxxxxxx> writes: > Looks fine to me. Only, since you're using a separate semaphore for > priority updates - which drivers will probably not apply in addition to > the hardware access semaphore around execution of SET ioctls - it might > be better to modify v4l2_prio_change() so that the new prio is set > before the old one is released. Else a low-prio SET ioctl might get > through in the middle (e.g. between a change from interactive to record > level.) Good point. And I think when doing updates in set-release order we can drop the lock altogether and use atomic_t for the prios array instead. Gerd -- sigfault