2013-09-10 16:23:22

by Tim Gardner

[permalink] [raw]
Subject: [PATCH 3.12-rc1] USB: input: cm109.c: Convert high volume dev_err() to dev_err_ratelimited()

BugLink: http://bugs.launchpad.net/bugs/1222850

This input device can get into a state that produces a high
volume of device status errors. Attempt to throttle these
error messages such that the kernel log is not flooded.

Cc: Dmitry Torokhov <[email protected]>
Signed-off-by: Tim Gardner <[email protected]>
---
drivers/input/misc/cm109.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 082684e..8ec72bc 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -351,7 +351,8 @@ static void cm109_urb_irq_callback(struct urb *urb)
if (status) {
if (status == -ESHUTDOWN)
return;
- dev_err(&dev->intf->dev, "%s: urb status %d\n", __func__, status);
+ dev_err_ratelimited(&dev->intf->dev, "%s: urb status %d\n",
+ __func__, status);
}

/* Special keys */
@@ -419,7 +420,8 @@ static void cm109_urb_ctl_callback(struct urb *urb)
dev->ctl_data->byte[3]);

if (status)
- dev_err(&dev->intf->dev, "%s: urb status %d\n", __func__, status);
+ dev_err_ratelimited(&dev->intf->dev, "%s: urb status %d\n",
+ __func__, status);

spin_lock(&dev->ctl_submit_lock);

@@ -436,7 +438,7 @@ static void cm109_urb_ctl_callback(struct urb *urb)
dev->irq_urb_pending = 1;
error = usb_submit_urb(dev->urb_irq, GFP_ATOMIC);
if (error)
- dev_err(&dev->intf->dev,
+ dev_err_ratelimited(&dev->intf->dev,
"%s: usb_submit_urb (urb_irq) failed %d\n",
__func__, error);
}
@@ -480,7 +482,7 @@ static void cm109_toggle_buzzer_sync(struct cm109_dev *dev, int on)
dev->ctl_data,
USB_PKT_LEN, USB_CTRL_SET_TIMEOUT);
if (error < 0 && error != -EINTR)
- dev_err(&dev->intf->dev, "%s: usb_control_msg() failed %d\n",
+ dev_err_ratelimited(&dev->intf->dev, "%s: usb_control_msg() failed %d\n",
__func__, error);
}

@@ -542,8 +544,9 @@ static int cm109_input_open(struct input_dev *idev)

error = usb_submit_urb(dev->urb_ctl, GFP_KERNEL);
if (error)
- dev_err(&dev->intf->dev, "%s: usb_submit_urb (urb_ctl) failed %d\n",
- __func__, error);
+ dev_err_ratelimited(&dev->intf->dev,
+ "%s: usb_submit_urb (urb_ctl) failed %d\n", __func__,
+ error);
else
dev->open = 1;

@@ -716,7 +719,7 @@ static int cm109_usb_probe(struct usb_interface *intf,
pipe = usb_rcvintpipe(udev, endpoint->bEndpointAddress);
ret = usb_maxpacket(udev, pipe, usb_pipeout(pipe));
if (ret != USB_PKT_LEN)
- dev_err(&intf->dev, "invalid payload size %d, expected %d\n",
+ dev_err_ratelimited(&intf->dev, "invalid payload size %d, expected %d\n",
ret, USB_PKT_LEN);

/* initialise irq urb */
--
1.7.9.5


2013-09-19 21:52:53

by Dmitry Torokhov

[permalink] [raw]
Subject: Re: [PATCH 3.12-rc1] USB: input: cm109.c: Convert high volume dev_err() to dev_err_ratelimited()

Hi Tim,

On Tue, Sep 10, 2013 at 10:23:13AM -0600, Tim Gardner wrote:
> BugLink: http://bugs.launchpad.net/bugs/1222850
>
> This input device can get into a state that produces a high
> volume of device status errors. Attempt to throttle these
> error messages such that the kernel log is not flooded.
>

Only 2 of these printks need to be rate-limited, as other failures are
fatal to the driver since it will not resubmit the IO.

Also I think we need to try and resubmit control URB to try and execute
buzzer command if previous one failed.

BTW, EPROTO/EILSEQ errors mentioned in the launchpad bug seem to relate
to timeout/CRC errors reported by the host controller, so it must indeed
be the extender that is misbehaving.

Thanks.

--
Dmitry


Input: cm109 - convert high volume dev_err() to dev_err_ratelimited()

From: Tim Gardner <[email protected]>

BugLink: http://bugs.launchpad.net/bugs/1222850

This input device can get into a state that produces a high
volume of device status errors. Attempt to throttle these
error messages such that the kernel log is not flooded.

Cc: Dmitry Torokhov <[email protected]>
Signed-off-by: Tim Gardner <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/misc/cm109.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 082684e..9365535 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -351,7 +351,9 @@ static void cm109_urb_irq_callback(struct urb *urb)
if (status) {
if (status == -ESHUTDOWN)
return;
- dev_err(&dev->intf->dev, "%s: urb status %d\n", __func__, status);
+ dev_err_ratelimited(&dev->intf->dev, "%s: urb status %d\n",
+ __func__, status);
+ goto out;
}

/* Special keys */
@@ -418,8 +420,12 @@ static void cm109_urb_ctl_callback(struct urb *urb)
dev->ctl_data->byte[2],
dev->ctl_data->byte[3]);

- if (status)
- dev_err(&dev->intf->dev, "%s: urb status %d\n", __func__, status);
+ if (status) {
+ if (status == -ESHUTDOWN)
+ return;
+ dev_err_ratelimited(&dev->intf->dev, "%s: urb status %d\n",
+ __func__, status);
+ }

spin_lock(&dev->ctl_submit_lock);

@@ -427,7 +433,7 @@ static void cm109_urb_ctl_callback(struct urb *urb)

if (likely(!dev->shutdown)) {

- if (dev->buzzer_pending) {
+ if (dev->buzzer_pending || status) {
dev->buzzer_pending = 0;
dev->ctl_urb_pending = 1;
cm109_submit_buzz_toggle(dev);

2013-09-23 17:51:11

by Tim Gardner

[permalink] [raw]
Subject: Re: [PATCH 3.12-rc1] USB: input: cm109.c: Convert high volume dev_err() to dev_err_ratelimited()

On 09/19/2013 02:52 PM, Dmitry Torokhov wrote:
> Hi Tim,
>
> On Tue, Sep 10, 2013 at 10:23:13AM -0600, Tim Gardner wrote:
>> BugLink: http://bugs.launchpad.net/bugs/1222850
>>
>> This input device can get into a state that produces a high
>> volume of device status errors. Attempt to throttle these
>> error messages such that the kernel log is not flooded.
>>
>
> Only 2 of these printks need to be rate-limited, as other failures are
> fatal to the driver since it will not resubmit the IO.
>
> Also I think we need to try and resubmit control URB to try and execute
> buzzer command if previous one failed.
>
> BTW, EPROTO/EILSEQ errors mentioned in the launchpad bug seem to relate
> to timeout/CRC errors reported by the host controller, so it must indeed
> be the extender that is misbehaving.
>
> Thanks.
>

Looks good to me.

rtg
--
Tim Gardner [email protected]