<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb, branch v3.18.62</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.62</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.62'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-07-15T08:14:40+00:00</updated>
<entry>
<title>USB: serial: qcserial: new Sierra Wireless EM7305 device ID</title>
<updated>2017-07-15T08:14:40+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2017-06-13T17:11:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02de02fe2b90be589615c8ed5c8ecc07f28b9a9d'/>
<id>urn:sha1:02de02fe2b90be589615c8ed5c8ecc07f28b9a9d</id>
<content type='text'>
commit 996fab55d864ed604158f71724ff52db1c2454a3 upstream.

A new Sierra Wireless EM7305 device ID used in a Toshiba laptop.

Reported-by: Petr Kloc &lt;petr_kloc@yahoo.com&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: serial: option: add two Longcheer device ids</title>
<updated>2017-07-15T08:14:40+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-06-12T14:30:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=79fc0784b6271ca16ab3d1b637cd6fb432c123a1'/>
<id>urn:sha1:79fc0784b6271ca16ab3d1b637cd6fb432c123a1</id>
<content type='text'>
commit 8fb060da715ad10fe956d7c0077b2fb0c12bb9d7 upstream.

Add two Longcheer device-id entries which specifically enables a
Telewell TW-3G HSPA+ branded modem (0x9801).

Reported-by: Teemu Likonen &lt;tlikonen@iki.fi&gt;
Reported-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Reported-by: Lars Melin &lt;larsm17@gmail.com&gt;
Tested-by: Teemu Likonen &lt;tlikonen@iki.fi&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: usbip: set buffer pointers to NULL after free</title>
<updated>2017-07-15T08:14:39+00:00</updated>
<author>
<name>Michael Grzeschik</name>
<email>m.grzeschik@pengutronix.de</email>
</author>
<published>2017-05-22T11:02:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8432af134b0e03b3f7cc22e145faca35a48999b'/>
<id>urn:sha1:c8432af134b0e03b3f7cc22e145faca35a48999b</id>
<content type='text'>
commit b3b51417d0af63fb9a06662dc292200aed9ea53f upstream.

The usbip stack dynamically allocates the transfer_buffer and
setup_packet of each urb that got generated by the tcp to usb stub code.
As these pointers are always used only once we will set them to NULL
after use. This is done likewise to the free_urb code in vudc_dev.c.
This patch fixes double kfree situations where the usbip remote side
added the URB_FREE_BUFFER.

Signed-off-by: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Acked-by: Shuah Khan &lt;shuahkh@osg.samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Add USB quirk for HVR-950q to avoid intermittent device resets</title>
<updated>2017-07-15T08:14:39+00:00</updated>
<author>
<name>Devin Heitmueller</name>
<email>dheitmueller@kernellabs.com</email>
</author>
<published>2017-06-27T17:08:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d085cd019747cc551608074fec95a30442bc8e8b'/>
<id>urn:sha1:d085cd019747cc551608074fec95a30442bc8e8b</id>
<content type='text'>
commit 6836796de4019944f4ba4c99a360e8250fd2e735 upstream.

The USB core and sysfs will attempt to enumerate certain parameters
which are unsupported by the au0828 - causing inconsistent behavior
and sometimes causing the chip to reset.  Avoid making these calls.

This problem manifested as intermittent cases where the au8522 would
be reset on analog video startup, in particular when starting up ALSA
audio streaming in parallel - the sysfs entries created by
snd-usb-audio on streaming startup would result in unsupported control
messages being sent during tuning which would put the chip into an
unknown state.

Signed-off-by: Devin Heitmueller &lt;dheitmueller@kernellabs.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick</title>
<updated>2017-07-15T08:14:39+00:00</updated>
<author>
<name>Jeremie Rapin</name>
<email>rapinj@gmail.com</email>
</author>
<published>2017-06-28T16:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc75a5984dd14aa71c7aa76bb6f0333f6361bc43'/>
<id>urn:sha1:dc75a5984dd14aa71c7aa76bb6f0333f6361bc43</id>
<content type='text'>
commit fd90f73a9925f248d696bde1cfc836d9fda5570d upstream.

Added the USB serial device ID for the CEL ZigBee EM3588
radio stick.

Signed-off-by: Jeremie Rapin &lt;rapinj@gmail.com&gt;
Acked-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: dwc3: replace %p with %pK</title>
<updated>2017-07-15T08:14:39+00:00</updated>
<author>
<name>Felipe Balbi</name>
<email>felipe.balbi@linux.intel.com</email>
</author>
<published>2017-05-17T12:57:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=05d219d0d58c203a72f46bce92378c51feb1fc67'/>
<id>urn:sha1:05d219d0d58c203a72f46bce92378c51feb1fc67</id>
<content type='text'>
commit 04fb365c453e14ff9e8a28f1c46050d920a27a4a upstream.

%p will leak kernel pointers, so let's not expose the information on
dmesg and instead use %pK. %pK will only show the actual addresses if
explicitly enabled under /proc/sys/kernel/kptr_restrict.

Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: ehci-orion: fix probe for !GENERIC_PHY</title>
<updated>2017-07-15T08:14:39+00:00</updated>
<author>
<name>Jonas Gorski</name>
<email>jogo@openwrt.org</email>
</author>
<published>2015-08-23T13:01:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92c414a143539f9f4abfd385288e0e86056653f5'/>
<id>urn:sha1:92c414a143539f9f4abfd385288e0e86056653f5</id>
<content type='text'>
commit db1319e166c5e872c4be54eac4e47454133708cf upstream.

Commit d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
added support for optional phys, but devm_phy_optional_get returns
-ENOSYS if GENERIC_PHY is not enabled.

This causes probe failures, even when there are no phys specified:

[    1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38
[    1.449403] orion-ehci: probe of f1058000.usb failed with error -38

Similar to dwc3, treat -ENOSYS as no phy.

Fixes: d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")

Signed-off-by: Jonas Gorski &lt;jogo@openwrt.org&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Fix possibe deadlock</title>
<updated>2017-07-05T12:35:14+00:00</updated>
<author>
<name>Baolin Wang</name>
<email>baolin.wang@linaro.org</email>
</author>
<published>2016-12-08T11:55:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9b8f56f595dea7ac3655dbf2318444e4749cfc65'/>
<id>urn:sha1:9b8f56f595dea7ac3655dbf2318444e4749cfc65</id>
<content type='text'>
commit b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.

When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().

[   52.642225] c1 ======================================================
[   52.642228] c1 [ INFO: possible circular locking dependency detected ]
[   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
[   52.642241] c1 -------------------------------------------------------
[   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[   52.642270] c0  (udc_lock){+.+.+.}, at: [&lt;ffffffc00065aeec&gt;]
		usb_gadget_unregister_driver+0x3c/0xc8
[   52.642272] c1  but task is already holding lock:
[   52.642283] c0  (ffs_lock){+.+.+.}, at: [&lt;ffffffc00066b244&gt;]
		ffs_data_clear+0x30/0x140
[   52.642285] c1 which lock already depends on the new lock.
[   52.642287] c1
               the existing dependency chain (in reverse order) is:
[   52.642295] c0
	       -&gt; #1 (ffs_lock){+.+.+.}:
[   52.642307] c0        [&lt;ffffffc00012340c&gt;] __lock_acquire+0x20f0/0x2238
[   52.642314] c0        [&lt;ffffffc000123b54&gt;] lock_acquire+0xe4/0x298
[   52.642322] c0        [&lt;ffffffc000aaf6e8&gt;] mutex_lock_nested+0x7c/0x3cc
[   52.642328] c0        [&lt;ffffffc00066f7bc&gt;] ffs_func_bind+0x504/0x6e8
[   52.642334] c0        [&lt;ffffffc000654004&gt;] usb_add_function+0x84/0x184
[   52.642340] c0        [&lt;ffffffc000658ca4&gt;] configfs_composite_bind+0x264/0x39c
[   52.642346] c0        [&lt;ffffffc00065b348&gt;] udc_bind_to_driver+0x58/0x11c
[   52.642352] c0        [&lt;ffffffc00065b49c&gt;] usb_udc_attach_driver+0x90/0xc8
[   52.642358] c0        [&lt;ffffffc0006598e0&gt;] gadget_dev_desc_UDC_store+0xd4/0x128
[   52.642369] c0        [&lt;ffffffc0002c14e8&gt;] configfs_write_file+0xd0/0x13c
[   52.642376] c0        [&lt;ffffffc00023c054&gt;] vfs_write+0xb8/0x214
[   52.642381] c0        [&lt;ffffffc00023cad4&gt;] SyS_write+0x54/0xb0
[   52.642388] c0        [&lt;ffffffc000085ff0&gt;] el0_svc_naked+0x24/0x28
[   52.642395] c0
              -&gt; #0 (udc_lock){+.+.+.}:
[   52.642401] c0        [&lt;ffffffc00011e3d0&gt;] print_circular_bug+0x84/0x2e4
[   52.642407] c0        [&lt;ffffffc000123454&gt;] __lock_acquire+0x2138/0x2238
[   52.642412] c0        [&lt;ffffffc000123b54&gt;] lock_acquire+0xe4/0x298
[   52.642420] c0        [&lt;ffffffc000aaf6e8&gt;] mutex_lock_nested+0x7c/0x3cc
[   52.642427] c0        [&lt;ffffffc00065aeec&gt;] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642432] c0        [&lt;ffffffc00065995c&gt;] unregister_gadget_item+0x28/0x44
[   52.642439] c0        [&lt;ffffffc00066b34c&gt;] ffs_data_clear+0x138/0x140
[   52.642444] c0        [&lt;ffffffc00066b374&gt;] ffs_data_reset+0x20/0x6c
[   52.642450] c0        [&lt;ffffffc00066efd0&gt;] ffs_data_closed+0xac/0x12c
[   52.642454] c0        [&lt;ffffffc00066f070&gt;] ffs_ep0_release+0x20/0x2c
[   52.642460] c0        [&lt;ffffffc00023dbe4&gt;] __fput+0xb0/0x1f4
[   52.642466] c0        [&lt;ffffffc00023dd9c&gt;] ____fput+0x20/0x2c
[   52.642473] c0        [&lt;ffffffc0000ee944&gt;] task_work_run+0xb4/0xe8
[   52.642482] c0        [&lt;ffffffc0000cd45c&gt;] do_exit+0x360/0xb9c
[   52.642487] c0        [&lt;ffffffc0000cf228&gt;] do_group_exit+0x4c/0xb0
[   52.642494] c0        [&lt;ffffffc0000dd3c8&gt;] get_signal+0x380/0x89c
[   52.642501] c0        [&lt;ffffffc00008a8f0&gt;] do_signal+0x154/0x518
[   52.642507] c0        [&lt;ffffffc00008af00&gt;] do_notify_resume+0x70/0x78
[   52.642512] c0        [&lt;ffffffc000085ee8&gt;] work_pending+0x1c/0x20
[   52.642514] c1
              other info that might help us debug this:
[   52.642517] c1  Possible unsafe locking scenario:
[   52.642518] c1        CPU0                    CPU1
[   52.642520] c1        ----                    ----
[   52.642525] c0   lock(ffs_lock);
[   52.642529] c0                                lock(udc_lock);
[   52.642533] c0                                lock(ffs_lock);
[   52.642537] c0   lock(udc_lock);
[   52.642539] c1
                      *** DEADLOCK ***
[   52.642543] c1 1 lock held by usb ffs open/2808:
[   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: [&lt;ffffffc00066b244&gt;]
		ffs_data_clear+0x30/0x140
[   52.642557] c1 stack backtrace:
[   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[   52.642568] c1 Call trace:
[   52.642573] c1 [&lt;ffffffc00008b430&gt;] dump_backtrace+0x0/0x170
[   52.642577] c1 [&lt;ffffffc00008b5c0&gt;] show_stack+0x20/0x28
[   52.642583] c1 [&lt;ffffffc000422694&gt;] dump_stack+0xa8/0xe0
[   52.642587] c1 [&lt;ffffffc00011e548&gt;] print_circular_bug+0x1fc/0x2e4
[   52.642591] c1 [&lt;ffffffc000123454&gt;] __lock_acquire+0x2138/0x2238
[   52.642595] c1 [&lt;ffffffc000123b54&gt;] lock_acquire+0xe4/0x298
[   52.642599] c1 [&lt;ffffffc000aaf6e8&gt;] mutex_lock_nested+0x7c/0x3cc
[   52.642604] c1 [&lt;ffffffc00065aeec&gt;] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642608] c1 [&lt;ffffffc00065995c&gt;] unregister_gadget_item+0x28/0x44
[   52.642613] c1 [&lt;ffffffc00066b34c&gt;] ffs_data_clear+0x138/0x140
[   52.642618] c1 [&lt;ffffffc00066b374&gt;] ffs_data_reset+0x20/0x6c
[   52.642621] c1 [&lt;ffffffc00066efd0&gt;] ffs_data_closed+0xac/0x12c
[   52.642625] c1 [&lt;ffffffc00066f070&gt;] ffs_ep0_release+0x20/0x2c
[   52.642629] c1 [&lt;ffffffc00023dbe4&gt;] __fput+0xb0/0x1f4
[   52.642633] c1 [&lt;ffffffc00023dd9c&gt;] ____fput+0x20/0x2c
[   52.642636] c1 [&lt;ffffffc0000ee944&gt;] task_work_run+0xb4/0xe8
[   52.642640] c1 [&lt;ffffffc0000cd45c&gt;] do_exit+0x360/0xb9c
[   52.642644] c1 [&lt;ffffffc0000cf228&gt;] do_group_exit+0x4c/0xb0
[   52.642647] c1 [&lt;ffffffc0000dd3c8&gt;] get_signal+0x380/0x89c
[   52.642651] c1 [&lt;ffffffc00008a8f0&gt;] do_signal+0x154/0x518
[   52.642656] c1 [&lt;ffffffc00008af00&gt;] do_notify_resume+0x70/0x78
[   52.642659] c1 [&lt;ffffffc000085ee8&gt;] work_pending+0x1c/0x20

Acked-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Cc: Jerry Zhang &lt;zhangjerry@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: fix deadlock at host remove by running watchdog correctly</title>
<updated>2017-07-05T12:35:12+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-01-11T15:10:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=daa5d1f0bffe48fba572209b18c05244eef264a5'/>
<id>urn:sha1:daa5d1f0bffe48fba572209b18c05244eef264a5</id>
<content type='text'>
commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 upstream.

If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.

xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.

Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.

Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0xffffffff or that
host is not halted before trying to stop the endpoint.

This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.

Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Howard Yen &lt;howard_yen@htc.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: gadget: f_fs: avoid out of bounds access on comp_desc</title>
<updated>2017-06-29T07:12:24+00:00</updated>
<author>
<name>William Wu</name>
<email>william.wu@rock-chips.com</email>
</author>
<published>2017-04-25T09:45:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1957b18db54491ca504ecc9a3d36634910f3f63'/>
<id>urn:sha1:e1957b18db54491ca504ecc9a3d36634910f3f63</id>
<content type='text'>
commit b7f73850bb4fac1e2209a4dd5e636d39be92f42c upstream.

Companion descriptor is only used for SuperSpeed endpoints,
if the endpoints are HighSpeed or FullSpeed, the Companion
descriptor will not allocated, so we can only access it if
gadget is SuperSpeed.

I can reproduce this issue on Rockchip platform rk3368 SoC
which supports USB 2.0, and use functionfs for ADB. Kernel
build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
the following BUG:

==================================================================
BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr ffffffc0601f6509
Read of size 1 by task swapper/0/0
============================================================================
BUG kmalloc-256 (Not tainted): kasan: bad access detected
----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
alloc_debug_processing+0x128/0x17c
___slab_alloc.constprop.58+0x50c/0x610
__slab_alloc.isra.55.constprop.57+0x24/0x34
__kmalloc+0xe0/0x250
ffs_func_bind+0x52c/0x99c
usb_add_function+0xd8/0x1d4
configfs_composite_bind+0x48c/0x570
udc_bind_to_driver+0x6c/0x170
usb_udc_attach_driver+0xa4/0xd0
gadget_dev_desc_UDC_store+0xcc/0x118
configfs_write_file+0x1a0/0x1f8
__vfs_write+0x64/0x174
vfs_write+0xe4/0x200
SyS_write+0x68/0xc8
el0_svc_naked+0x24/0x28
INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
...
Call trace:
[&lt;ffffff900808aab4&gt;] dump_backtrace+0x0/0x230
[&lt;ffffff900808acf8&gt;] show_stack+0x14/0x1c
[&lt;ffffff90084ad420&gt;] dump_stack+0xa0/0xc8
[&lt;ffffff90082157cc&gt;] print_trailer+0x188/0x198
[&lt;ffffff9008215948&gt;] object_err+0x3c/0x4c
[&lt;ffffff900821b5ac&gt;] kasan_report+0x324/0x4dc
[&lt;ffffff900821aa38&gt;] __asan_load1+0x24/0x50
[&lt;ffffff90089eb750&gt;] ffs_func_set_alt+0x224/0x3a0
[&lt;ffffff90089d3760&gt;] composite_setup+0xdcc/0x1ac8
[&lt;ffffff90089d7394&gt;] android_setup+0x124/0x1a0
[&lt;ffffff90089acd18&gt;] _setup+0x54/0x74
[&lt;ffffff90089b6b98&gt;] handle_ep0+0x3288/0x4390
[&lt;ffffff90089b9b44&gt;] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
[&lt;ffffff90089be85c&gt;] dwc_otg_pcd_handle_intr+0x1ec/0x298
[&lt;ffffff90089ad680&gt;] dwc_otg_pcd_irq+0x10/0x20
[&lt;ffffff9008116328&gt;] handle_irq_event_percpu+0x124/0x3ac
[&lt;ffffff9008116610&gt;] handle_irq_event+0x60/0xa0
[&lt;ffffff900811af30&gt;] handle_fasteoi_irq+0x10c/0x1d4
[&lt;ffffff9008115568&gt;] generic_handle_irq+0x30/0x40
[&lt;ffffff90081159b4&gt;] __handle_domain_irq+0xac/0xdc
[&lt;ffffff9008080e9c&gt;] gic_handle_irq+0x64/0xa4
...
Memory state around the buggy address:
  ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
 &gt;ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                       ^
  ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================

Signed-off-by: William Wu &lt;william.wu@rock-chips.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Cc: Jerry Zhang &lt;zhangjerry@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
