On 2017-04-24 16:59, Philipp Zabel wrote: > On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote: > [...] >>> How about an atomic use_count on the mux_control, a bool shared that is >>> only set by the first consumer, and controls whether selecting locks? >> >> That has the drawback that it is hard to restore the mux-control in a safe >> way so that exclusive consumers are allowed after the last shared consumer >> puts the mux away. > > True. > >> Agreed, it's a corner case, but I had this very similar >> patch going through the compiler when I got this mail. Does it work as well >> as what you suggested? > > Yes, this patch works just as well. Right, as expected :-) However, I don't like it much. It divides the mux consumers into two camps in a way that makes it difficult to select which camp a consumer should be in. E.g. consider the iio-mux. The current implementation only supports quick accesses that fit the mux_control_get_shared case. But if that mux in the future needs to grow continuous buffered accesses, I think there will be pressure to switch it over to the exclusive mode. Because that is a lot closer to what you are doing with the video-mux. And then what? It will be impossible to predict if the end user is going to use buffered accesses or not... So, I think the best approach is to skip the distinction between shared and exclusive consumers and instead implement the locking with an ordinary semaphore (instead of the old rwsem or the current mutex). Semaphores don't have the property that the same task should down/up them (mutexes require that for lock/unlock, and is also the reason for the lockdep complaint) and thus fits better for long-time use such as yours or the above iio-mux with buffered accesses. It should also hopefully be cheaper that an rwsem, and not have any downgrade_write calls thus possibly keeping Greg sufficiently happy... Sure, consumers can still dig themselves into a hole by not calling deselect as they should, but at least I think it can be made to work w/o dividing the consumers... Cheers, peda -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
