On Mon, Nov 22, 2010 at 01:40:28PM -0500, Jarod Wilson wrote: >On Nov 22, 2010, at 12:42 PM, Mauro Carvalho Chehab wrote: > >> Em 19-11-2010 21:43, David Härdeman escreveu: >>> Convert boolean variables to use the corresponding data type. >>> >>> Signed-off-by: David Härdeman <david@xxxxxxxxxxx> >> >> Waiting for Jarod's comments, but the same comment I made on the previous >> patch applies to this one. >>> --- >>> drivers/media/rc/mceusb.c | 62 +++++++++++++++++++-------------------------- >>> 1 files changed, 26 insertions(+), 36 deletions(-) >>> >>> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c >>> index ef9bddc..bb6e2dc 100644 >>> --- a/drivers/media/rc/mceusb.c >>> +++ b/drivers/media/rc/mceusb.c >>> @@ -103,9 +103,9 @@ >>> >>> /* module parameters */ >>> #ifdef CONFIG_USB_DEBUG >>> -static int debug = 1; >>> +static bool debug = true; >>> #else >>> -static int debug; >>> +static bool debug; >>> #endif >> >> Not sure if we should convert debug parameter to bool: we may need to have >> extra debug levels, or maybe just convert to use dev_dbg(), allowing enabling >> them via dynamic_printk. > >I actually was considering implementing multiple debug levels at >some point, and many of the debug printk's in here already use >dev_dbg, which tbh, I can't stand -- the whole debugfs dance is >non-intuitive to me and more hassle than simply loading a module >with a param (or echoing a value into /sys/modules/foo). But for >the moment, I'm not particularly attached to either bool or int >for the param, it can be changed again in the future if need be. I can respin the patch to only bool-ify the non modparam stuff? >This bit looked a bit odd to me though. Isn't the :1 redundant if we've >switched to bools? Bools are still larger than one bit. I can remove the :1 if you want me to, it'll probably make the code a bit faster on some architectures which do not have a nice way of dealing with bitfields. -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
