OpenWrt – Blame information for rev 4
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
4 | office | 1 | From: Alexey Brodkin <abrodkin@synopsys.com> |
2 | Subject: usb: Remove annoying warning about bogus URB |
||
3 | |||
4 | When ath9k-htc Wi-Fi dongle is used with generic OHCI controller |
||
5 | infinite stream of warnings appears in debug console like this: |
||
6 | -------------------------->8---------------------- |
||
7 | usb 1-1: new full-speed USB device number 2 using ohci-platform |
||
8 | usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested |
||
9 | usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: |
||
10 | 51008 |
||
11 | ------------[ cut here ]------------ |
||
12 | WARNING: CPU: 0 PID: 19 at drivers/usb/core/urb.c:449 |
||
13 | usb_submit_urb+0x1b4/0x498() |
||
14 | usb 1-1: BOGUS urb xfer, pipe 1 != type 3 |
||
15 | Modules linked in: |
||
16 | CPU: 0 PID: 19 Comm: kworker/0:1 Not tainted |
||
17 | 4.4.0-rc4-00017-g00e2d79-dirty #3 |
||
18 | Workqueue: events request_firmware_work_func |
||
19 | |||
20 | Stack Trace: |
||
21 | arc_unwind_core.constprop.1+0xa4/0x110 |
||
22 | ---[ end trace 649ef8c342817fc2 ]--- |
||
23 | ------------[ cut here ]------------ |
||
24 | WARNING: CPU: 0 PID: 19 at drivers/usb/core/urb.c:449 |
||
25 | usb_submit_urb+0x1b4/0x498() |
||
26 | usb 1-1: BOGUS urb xfer, pipe 1 != type 3 |
||
27 | Modules linked in: |
||
28 | CPU: 0 PID: 19 Comm: kworker/0:1 Tainted: G W |
||
29 | 4.4.0-rc4-00017-g00e2d79-dirty #3 |
||
30 | Workqueue: events request_firmware_work_func |
||
31 | |||
32 | Stack Trace: |
||
33 | arc_unwind_core.constprop.1+0xa4/0x110 |
||
34 | ---[ end trace 649ef8c342817fc3 ]--- |
||
35 | ------------[ cut here ]------------ |
||
36 | -------------------------->8---------------------- |
||
37 | |||
38 | There're some discussions in mailing lists proposing to disable |
||
39 | that particular check alltogether and magically all seem to work |
||
40 | fine with muted warning. |
||
41 | |||
42 | Anyways new thread on that regard could be found here: |
||
43 | http://lists.infradead.org/pipermail/linux-snps-arc/2016-July/001310.html |
||
44 | |||
45 | Let's see what comes out of that new discussion, hopefully patching |
||
46 | of generic USB stuff won't be required then. |
||
47 | |||
48 | Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> |
||
49 | --- |
||
50 | drivers/leds/Makefile | 1 + |
||
51 | drivers/leds/trigger/Kconfig | 7 +++++++ |
||
52 | 2 files changed, 8 insertions(+) |
||
53 | |||
54 | --- a/drivers/leds/Makefile |
||
55 | +++ b/drivers/leds/Makefile |
||
56 | @@ -77,3 +77,4 @@ obj-$(CONFIG_LEDS_DAC124S085) += leds-d |
||
57 | |||
58 | # LED Triggers |
||
59 | obj-$(CONFIG_LEDS_TRIGGERS) += trigger/ |
||
60 | +obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o |
||
61 | --- a/drivers/leds/trigger/Kconfig |
||
62 | +++ b/drivers/leds/trigger/Kconfig |
||
63 | @@ -126,4 +126,11 @@ config LEDS_TRIGGER_PANIC |
||
64 | a different trigger. |
||
65 | If unsure, say Y. |
||
66 | |||
67 | +config LEDS_TRIGGER_NETDEV |
||
68 | + tristate "LED Netdev Trigger" |
||
69 | + depends on NET && LEDS_TRIGGERS |
||
70 | + help |
||
71 | + This allows LEDs to be controlled by network device activity. |
||
72 | + If unsure, say Y. |
||
73 | + |
||
74 | endif # LEDS_TRIGGERS |