[PATCH] Drop __must_check from bus_for_each_drv()

[Jean Delvare]

There is little rationale for marking bus_for_each_drv() __must_check.
It is more of an iteration helper than a real function. You don't know
in advance which callback it will be used on, so you have no clue how
important it can be to check the returned value. In practice, this
helper function can be used for best-effort tasks.

As a matter of fact, bus_for_each_dev() is not marked __must_check.
So remove it from bus_for_each_drv() as well. This is the same that
was done back in October 2006 by Russell King for
device_for_each_child(), for exactly the same reasons.

Signed-off-by: Jean Delvare <khali@xxxxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxx>
---
Background: I am calling bus_for_each_drv() in i2c-core, putting the
result in a dummy variable because I know it will always be 0. Now,
gcc 4.6 complains about variables that are set but never used, so I
was proposed ugly workarounds to silent this warning. I think it is
much saner to just acknowledge that this specific __must_check was
not desirable, and clean up the code.

 include/linux/device.h |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-2.6.35-rc3.orig/include/linux/device.h	2010-05-31 09:59:56.000000000 +0200
+++ linux-2.6.35-rc3/include/linux/device.h	2010-06-16 09:37:55.000000000 +0200
@@ -84,9 +84,8 @@ struct device *bus_find_device_by_name(s
 				       struct device *start,
 				       const char *name);
 
-int __must_check bus_for_each_drv(struct bus_type *bus,
-				  struct device_driver *start, void *data,
-				  int (*fn)(struct device_driver *, void *));
+int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
+		     void *data, int (*fn)(struct device_driver *, void *));
 
 void bus_sort_breadthfirst(struct bus_type *bus,
 			   int (*compare)(const struct device *a,


-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/