From: Arjan van de Ven <arjan@linux.intel.com> Date: Fri, 19 Sep 2008 21:03:06 -0700 Subject: [PATCH] debug: Introduce a dev_WARN() function in the line of dev_printk(), this patch introduces a dev_WARN() macro, that takes a struct device and then a printk format/args set of arguments. Unlike dev_printk(), the effect is that of WARN() in that a full warning message (including filename/line, module list, versions and a backtrace) is printed in addition to the device name and the arguments. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- include/linux/device.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/device.h b/include/linux/device.h index 4d8372d..2f9cdfa 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -539,6 +539,9 @@ extern const char *dev_driver_string(const struct device *dev); #define dev_info(dev, format, arg...) \ dev_printk(KERN_INFO , dev , format , ## arg) +#define dev_WARN(dev, format, arg...) \ + WARN(1, "Device: %s\n" format, dev_driver_string(dev), ## arg) + #ifdef DEBUG #define dev_dbg(dev, format, arg...) \ dev_printk(KERN_DEBUG , dev , format , ## arg) -- 1.5.5.1 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
From: Arjan van de Ven <arjan@linux.intel.com> Date: Fri, 19 Sep 2008 21:05:25 -0700 Subject: [PATCH] debug: use dev_WARN() rather than WARN_ON() in device_pm_add() device_pm_add() has a WARN_ON that is showing up relatively high on kerneloops.org, but unfortunately the WARN_ON is less than useful in that it doesn't print any information about what device is causing the issue. This patch fixes this by turning the WARN_ON() into the newly introduces dev_WARN() which will print information about the device in question. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- drivers/base/power/main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index bf6d355..b65667f 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -83,7 +83,7 @@ void device_pm_add(struct device *dev) * transition is in progress in order to avoid leaving them * unhandled down the road */ - WARN_ON(true); + dev_WARN(dev, "Parentless device registered during a PM transaction\n"); } list_add_tail(&dev->power.entry, &dpm_list); -- 1.5.5.1 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
I like the idea, but we already have dev_warn(), so dev_WARN() might be a bit confusing for people. Perhaps just documenting it with a docbook tag would suffice? thanks, greg k-h --
On Fri, 19 Sep 2008 21:26:30 -0700 I didn't think we could do kerneldoc for macros? But maybe I just misremember -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --
On Fri, 19 Sep 2008 21:26:30 -0700
I added a set of comments, and also ended up doing the below USB change
From 8a2fde5066bed00906df2fff1121d361e9e552f7 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sat, 20 Sep 2008 10:35:51 -0700
Subject: [PATCH] usb: turn dev_warn+WARN_ON combos into dev_WARN
dev_WARN is both compacter and gives better debug information
than just a WARN_ON, since people and tools will copy the device
information message together with the WARN_ON in bug reports.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
drivers/usb/host/uhci-q.c | 24 ++++++++----------------
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/uhci-q.c b/drivers/usb/host/uhci-q.c
index db64593..1f0c2cf 100644
--- a/drivers/usb/host/uhci-q.c
+++ b/drivers/usb/host/uhci-q.c
@@ -123,14 +123,10 @@ static struct uhci_td *uhci_alloc_td(struct uhci_hcd *uhci)
static void uhci_free_td(struct uhci_hcd *uhci, struct uhci_td *td)
{
- if (!list_empty(&td->list)) {
- dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
- WARN_ON(1);
- }
- if (!list_empty(&td->fl_list)) {
- dev_warn(uhci_dev(uhci), "td %p still in fl_list!\n", td);
- WARN_ON(1);
- }
+ if (!list_empty(&td->list))
+ dev_WARN(uhci_dev(uhci), "td %p still in list!\n", td);
+ if (!list_empty(&td->fl_list))
+ dev_WARN(uhci_dev(uhci), "td %p still in fl_list!\n", td);
dma_pool_free(uhci->td_pool, td, td->dma_handle);
}
@@ -295,10 +291,8 @@ static struct uhci_qh *uhci_alloc_qh(struct uhci_hcd *uhci,
static void uhci_free_qh(struct uhci_hcd *uhci, struct uhci_qh *qh)
{
WARN_ON(qh->state != QH_STATE_IDLE && qh->udev);
- if (!list_empty(&qh->queue)) {
- dev_warn(uhci_dev(uhci), "qh %p list not empty!\n", qh);
- WARN_ON(1);
- }
+ if (!list_empty(&qh->queue))
+ dev_WARN(uhci_dev(uhci), "qh %p list not empty!\n", qh);
list_del(&qh->node);
if (qh->udev) {
@@ -746,11 +740,9 @@ static void uhci_free_urb_priv(struct ...Ok, that looks good, care to resend all of these, with the changed original one so that I can apply them? thanks, greg k-h --
