Hi Joe and Marcel, On Wed, Jun 29, 2011 at 3:00 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Joe, > >> > The pr_<level> ones are nice and I wished we had them all back in the >> > days, but the NFC ones actually could take the controller as argument >> > and then us the dev_* versions of these commands. >> >> I do think that if there's a controller struct that's always >> or mostly used with nfc_<level>, then it should be added and >> passed to the functions arguments, maybe with NULL used where >> necessary. >> >> > At this stage of the project it is a bit too early to tell I guess. >> > > I think emitting __func__ rarely adds useful information. >> > Depends on how you are using your debug statements. I find it really >> > helpful since then you can keep the text detail to a minimum. >> >> I don't disagree that while debugging function names >> and tracing function entries/exits are useful. >> >> Today, dynamic_debug can add __func__ to the output as >> desired so I think that it's not really necessary >> to add to any <foo>_dbg callsite. > > I did not know that. Then we might should go ahead and also cleanup the > Bluetooth subsystem. That's true only for pr_debug() function. You cannot add __func__ info on dev_dbg() calls dynamically. So, for net/nfc/* I propose to use directly pr_*() functions. For device drivers the following macros would be provided: #define nfc_dev_info(dev, fmt, arg...) dev_info((dev), "NFC: " fmt, ## arg) #define nfc_dev_err(dev, fmt, arg...) dev_err((dev), "%s: " fmt, __func__, ## arg) #define nfc_dev_dbg(dev, fmt, arg...) dev_dbg((dev), "%s: " fmt, __func__, ## arg) What do you think? Aloisio -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html