regulator: core: avoid unused variable warning

The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function:

drivers/regulator/core.c: In function 'regulator_lock_supply':
drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable]

To avoid the warning, this patch moves the postincrement outside of the call mutex_lock_nested(), which is enough to shut up gcc about it.

We had some discussion about changing mutex_lock_nested to an inline function, which would make the code do the right thing here, but in the end decided against it, in order to guarantee that mutex_lock_nested() does not introduced overhead without CONFIG_DEBUG_LOCK_ALLOC.

---
The patch that introduced the warning is now in 4.4-rc1, and I think this patch is still the least ugly workaround we found.

index 4cf1390784e5..cf5371ee0be4 100644
@@ -142,7 +142,9 @@ static void regulator_lock_supply(struct regulator_dev *rdev)
 	int i = 0;
 
 	while (1) {
-		mutex_lock_nested(&rdev->mutex, i++);
+		mutex_lock_nested(&rdev->mutex, i);
+		i++;
+
 		supply = rdev->supply;
 
 		if (!rdev->supply)

Can we please at least have a comment explaining that this is working
around lockdep limitations?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151120/faef10f5/attachment.sig>

Not sure which limitation you are referring to. Maybe you could just modify the changelog text as you like when applying the patch?

The limitation we talked about in the previous thread was about the maximum of 8 nesting levels, but my patch here doesn't address that at all.

I tried to capture the fact that mutex_lock_nested() intentionally doesn't evaluate its second argument when CONFIG_DEBUG_LOCK_ALLOC is not set, but that appears to be less of a limitation than a choice of the interface.

Arnd

That's the limitation (or intereface choice or whatever) that I'm
talking about - the code looks like a function call so not evaulating
the second argument is surprising. I'm looking for something in the
code rather than the changelog so it doesn't get cleaned up later.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151120/5b9d2824/attachment.sig>

Got it. Will send a new version soon.

Arnd