> > I like the automated editing because it certainly cuts down on typos, > > and even with this one, you can just move the new lock field upon > > inspection. Sadly, I don't think the script will apply too widely > > because the use of "_state" for driver global data isn't a standard, > > nor availability of that struct in the functions needing the locking. > I only saw three files that had the mlock and they followed the structure > with _state as suffix and only had mutex_lock for &indio_dev->mlock. > Hence, I went ahead with the script even though I knew it wasn't probably > very safe. If _state is useful, you can add a regular expression to the metavariable declaration to checkk for that. I think it would be something like: identifier x =~ "_state$"; but I don't actually know. I would prefer to use some more semantic concept to identify such a structure. For example, structures are often stored in other structures or passed to some generic function. Then you can get to the structure in a way that is based on its purpose rather than its name. julia -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
