On Sat, Feb 11, 2023 at 10:10:23PM -0500, Kent Overstreet wrote: > So IMO the more correct way to do this would be to change > device_initialize() to __device_initialize(), have it take a > lock_class_key as a parameter, and then use __mutex_init() instead of > mutex_init(). Yes, maybe. The increase in code size might outweigh the space saved. > But let's think about this more. Will there ever be situations where > lock ordering is dependent on what hardware is plugged into what, or > what hardware is plugged in first? Device lock ordering is always dependent on what hardware is plugged into what. However, I'm not aware of any situations where, given two different kinds of hardware, either one could be plugged into the other. Such things may exist but I can't think of any examples. On the other hand, there are obvious cases where two pieces of the _same_ kind of hardware can be plugged together in either order. USB hubs are a good example. Consider the possibility that a driver might want to lock all of a device's children at once. (I don't know if this ever happens, but it might.) Provided it acquires the parent device's lock first, this is utterly safe no matter what order the children are locked in. Try telling that to lockdep! In the end, we'd probably have to enforce a single fixed ordering. Alan Stern
