27 Nov, 2011
40 commits
-
commit 09f363c7363eb10cfb4b82094bd7064e5608258b upstream.
The callback must not return -1 when nr_to_scan is zero. Fix the bug in
fs/super.c and add this requirement to the callback specification.Signed-off-by: Mikulas Patocka
Cc: Dave Chinner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 93840ac40bb0d0f177ef8af74e64671be67e8c37 upstream.
Function tt_response_fill_table() actually uses a tt_local_entry pointer to
iterate either over the local or the global table entries (it depends on the
what hash table is passed as argument). To iterate over such entries the
hlist_for_each_entry_rcu() macro has to access their "hash_entry" field which
MUST be at the same position in both the tt_global/local_entry structures.Reported-by: Simon Wunderlich
Signed-off-by: Antonio Quartulli
Signed-off-by: Marek Lindner
Signed-off-by: Greg Kroah-Hartman -
commit 6e8014947d6469df1566e9e253805557c5c0e4e0 upstream.
After removing the batman-adv module, the hash may be already gone
when tt_global_del_orig() tries to clean the hash. This patch adds
a sanity check to avoid this.Signed-off-by: Simon Wunderlich
Tested-by: Alexey Fisher
Signed-off-by: Marek Lindner
Signed-off-by: Greg Kroah-Hartman -
commit 531027fcddbcf81c9937dd04f08a7e8f11fd47d2 upstream.
struct tt_global_entry holds a reference to an orig_node which must be
decremented before deallocating the structure.Signed-off-by: Simon Wunderlich
Tested-by: Alexey Fisher
Signed-off-by: Marek Lindner
Signed-off-by: Greg Kroah-Hartman -
commit 9d8523931f7f5eb8900077f0da0fbe6b8ad0010b upstream.
In the TT_RESPONSE packet, the number of carried entries is not correctly set.
This leads to a wrong interpretation of the packet payload on the receiver side
causing random entries to be added to the global translation table. Therefore
the latter gets always corrupted, triggering a table recovery all the time.Signed-off-by: Antonio Quartulli
Signed-off-by: Marek Lindner
Signed-off-by: Greg Kroah-Hartman -
commit 31901264511cf20c5ed33b8649a3ca9ce28df60b upstream.
Currently the counter of tt_local_entry structures (tt_local_num) is incremented
each time the tt_local_reset_flags() is invoked causing the node to send wrong
TT_REPONSE packets containing a copy of non-initialised memory thus corrupting
other nodes global translation table and making higher level communication
impossible.Reported-by: Junkeun Song
Signed-off-by: Antonio Quartulli
Acked-by: Junkeun Song
Signed-off-by: Marek Lindner
Signed-off-by: Greg Kroah-Hartman -
commit c4f9c4c2b3f1831e932e04db992cf6fe92c2a95a upstream.
It's needed for 3 pipe support as well as just regular functionality
(e.g. DisplayPort).Signed-off-by: Jesse Barnes
Tested-by: Adam Jackson
Tested-by: Eugeni Dodonov
Signed-off-by: Keith Packard
Signed-off-by: Robert Hooker
Signed-off-by: Greg Kroah-Hartman -
commit 65a21cd65316145f9302594be8e69074369e1050 upstream.
The cursor regs have moved around, add the offsets and new macros for
getting at them.Signed-off-by: Jesse Barnes
Tested-By: Eugeni Dodonov
Reviewed-By: Eugeni Dodonov
Signed-off-by: Keith Packard
Signed-off-by: Robert Hooker
Signed-off-by: Greg Kroah-Hartman -
commit 0d145d7d4a241c321c832a810bb6edad18e2217b upstream.
The following patch contains additional affected webcam models, on top of the
patches commited to linux-next 2394d67e446bf616a0885167d5f0d397bdacfdfc
and 5b253d88cc6c65a23cefc457a5a4ef139913c5fcSigned-off-by: sordna
Cc: Oliver Neukum
Signed-off-by: Greg Kroah-Hartman -
commit 60c71ca972a2dd3fd9d0165b405361c8ad48349b upstream.
We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
This patch resolves the issue.Signed-off-by: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 811c926c538f7e8d3c08b630dd5844efd7e000f6 upstream.
The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.For that we reverse the order of uframe allocation (last uframe first).
Here an example :
hid interrupt stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------There no place for iso IN stream (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.With the patch this become.
iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------iso IN stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------Signed-off-by: Matthieu Castet
Signed-off-by: Thomas Poussevin
Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit 2f640bf4c94324aeaa1b6385c10aab8c5ad1e1cf upstream.
The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands;
shorter commands must be padded. Simon Detheridge reports that his
3-TB USB disk drive claims to use the 8020i protocol (which is
normally meant for ATAPI devices like CD drives), and because of its
large size, the disk drive requires the use of 16-byte commands.
However the usb_stor_pad12_command() routine in usb-storage always
sets the command length to 12, making the drive impossible to use.Since the SFF-8020i specification allows for 16-byte commands in
future extensions, we may as well accept them. This patch (as1490)
changes usb_stor_pad12_command() to leave commands larger than 12
bytes alone rather than truncating them.Signed-off-by: Alan Stern
Tested-by: Simon Detheridge
CC: Matthew Dharm
Signed-off-by: Greg Kroah-Hartman -
commit b1ffb4c851f185e9051ba837c16d9b84ef688d26 upstream.
Fix for ftdi_set_termios() glitching output
ftdi_set_termios() is constantly setting the baud rate, data bits and parity
unnecessarily on every call, . When called while characters are being
transmitted can cause the FTDI chip to corrupt the serial port bit stream
output by stalling the output half a bit during the output of a character.
Simple fix by skipping this setting if the baud rate/data bits/parity are
unchanged.Signed-off-by: Andrew Worsley
Signed-off-by: Greg Kroah-Hartman -
commit 583182ba5f02c8c9be82ea550f2051eaec15b975 upstream.
This patch for the usb serial ark3116 driver fixes an initialisation
ordering bug that gets triggered on hotplug when using at least recent
debian/ubuntu userspace. Without it, ark3116 serial cables don't work.Signed-off-by: Bart Hartgers
Tested-by: law_ence.dev@ntlworld.com
Signed-off-by: Greg Kroah-Hartman -
commit 97ff22ee3b4cb3a334f7385e269773141aed702f upstream.
This patch (as1491) works around a bug in GCC-3.4.6, which is still
supposed to be supported. The number of microseconds in the udelay()
call in quirk_usb_disable_ehci() is fixed at 100, but the compiler
doesn't understand this and generates a link-time error. So we
replace the otherwise unused variable "delta" with a simple constant
100. This same pattern is already used in other delay loops in that
source file.Signed-off-by: Alan Stern
Reported-by: Konrad Rzepecki
Tested-by: Konrad Rzepecki
Signed-off-by: Greg Kroah-Hartman -
commit 5dc2470c602da8851907ec18942cd876c3b4ecc1 upstream.
There's a race between the USB disconnect handler and the TTY close
handler which may cause the acm object to be freed while it's still
being used. This may lead to things likehttp://article.gmane.org/gmane.linux.usb.general/54250
and
https://lkml.org/lkml/2011/5/29/64
This is the simplest fix I could come up with. Holding on to open_mutex
while closing the TTY device prevents acm_disconnect() from freeing the
acm object between acm->port.count drops to 0 and the TTY side of the
cleanups are finalized.Signed-off-by: Havard Skinnemoen
Cc: Oliver Neukum
Signed-off-by: Greg Kroah-Hartman -
commit 731ad81e2dd97e3f222361f7b3ff4b35639e46af upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA
Signed-off-by: Greg Kroah-Hartman -
commit 0c16595539b612fe948559433dda08ff96a8bdc7 upstream.
I get report from customer that his usb-serial
converter doesn't work well,it sometimes work,
but sometimes it doesn't.The usb-serial converter's id:
vendor_id product_id
0x4348 0x5523Then I search the usb-serial codes, and there are
two drivers announce support this device, pl2303
and ch341, commit 026dfaf1 cause it. Through many
times to test, ch341 works well with this device,
and pl2303 doesn't work quite often(it just work quite little).ch341 works well with this device, so we doesn't
need pl2303 to support.I try to revert 026dfaf1 first,
but it failed. So I prepare this patch by hand to revert it.Signed-off-by: Wang YanQing
Signed-off-by: Greg Kroah-Hartman -
commit 4aa3648c719265bac9c2742c9ebb043e6dbdd790 upstream.
Signed-off-by: Ferenc Wagner
Signed-off-by: Greg Kroah-Hartman -
commit 46b5a277ed90317a4d17e936c16037e76011b219 upstream.
This patch adds new PIDs for ZTE 3G modem, after we confirm it and tested.
Thanks for Dan's work at kernel option devier.Signed-off-by: Alvin.Zheng
Signed-off-by: wsalvin
Signed-off-by: Greg Kroah-Hartman -
commit f69e3120df82391a0ee8118e0a156239a06b2afb upstream.
This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well. Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.Signed-off-by: Alan Stern
CC: Sarah Sharp
Tested-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f43d623164022dcbf6750ef220b7a1133a1183eb upstream.
While debugging a usb3 problem, I stumbled upon this lockdep warning.
Oct 18 21:41:17 dhcp47-74 kernel: =================================
Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
Oct 18 21:41:17 dhcp47-74 kernel: [] __lock_acquire+0x781/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [] xhci_irq+0x3a/0x1960 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] xhci_msi_irq+0x31/0x40 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] handle_irq_event_percpu+0x85/0x320
Oct 18 21:41:17 dhcp47-74 kernel: [] handle_irq_event+0x48/0x70
Oct 18 21:41:17 dhcp47-74 kernel: [] handle_edge_irq+0x6d/0x130
Oct 18 21:41:17 dhcp47-74 kernel: [] handle_irq+0x49/0xa0
Oct 18 21:41:17 dhcp47-74 kernel: [] do_IRQ+0x5d/0xe0
Oct 18 21:41:17 dhcp47-74 kernel: [] ret_from_intr+0x0/0x13
Oct 18 21:41:17 dhcp47-74 kernel: [] usb_set_device_state+0x8a/0x180
Oct 18 21:41:17 dhcp47-74 kernel: [] usb_add_hcd+0x2b8/0x730
Oct 18 21:41:17 dhcp47-74 kernel: [] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] local_pci_probe+0x5f/0xd0
Oct 18 21:41:17 dhcp47-74 kernel: [] pci_device_probe+0x119/0x120
Oct 18 21:41:17 dhcp47-74 kernel: [] driver_probe_device+0xa3/0x2c0
Oct 18 21:41:17 dhcp47-74 kernel: [] __driver_attach+0xab/0xb0
Oct 18 21:41:17 dhcp47-74 kernel: [] bus_for_each_dev+0x6c/0xa0
Oct 18 21:41:17 dhcp47-74 kernel: [] driver_attach+0x1e/0x20
Oct 18 21:41:17 dhcp47-74 kernel: [] bus_add_driver+0x1f8/0x2b0
Oct 18 21:41:17 dhcp47-74 kernel: [] driver_register+0x76/0x140
Oct 18 21:41:17 dhcp47-74 kernel: [] __pci_register_driver+0x66/0xe0
Oct 18 21:41:17 dhcp47-74 kernel: [] snd_timer_find+0x4a/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel: [] snd_timer_find+0xe/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel: [] do_one_initcall+0x43/0x180
Oct 18 21:41:17 dhcp47-74 kernel: [] sys_init_module+0x92/0x1f0
Oct 18 21:41:17 dhcp47-74 kernel: [] system_call_fastpath+0x16/0x1b
Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last enabled at (631984): [] _raw_spin_unlock_irq+0x30/0x50
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [] _raw_spin_lock_irq+0x19/0x90
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last enabled at (631980): [] _local_bh_enable+0x13/0x20
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: CPU0
Oct 18 21:41:17 dhcp47-74 kernel: ----
Oct 18 21:41:17 dhcp47-74 kernel: lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
Oct 18 21:41:17 dhcp47-74 kernel: #0: (&ep->stop_cmd_timer){+.-...}, at: [] run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
Oct 18 21:41:17 dhcp47-74 kernel: [] print_usage_bug+0x227/0x270
Oct 18 21:41:17 dhcp47-74 kernel: [] mark_lock+0x346/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [] __lock_acquire+0x61e/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [] ? mark_lock+0x213/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [] run_timer_softirq+0x20d/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [] __do_softirq+0xf2/0x3f0
Oct 18 21:41:17 dhcp47-74 kernel: [] ? lapic_next_event+0x1d/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [] ? clockevents_program_event+0x5e/0x90
Oct 18 21:41:17 dhcp47-74 kernel: [] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [] do_softirq+0x8d/0xc0
Oct 18 21:41:17 dhcp47-74 kernel: [] irq_exit+0xe5/0x100
Oct 18 21:41:17 dhcp47-74 kernel: [] smp_apic_timer_interrupt+0x6e/0x99
Oct 18 21:41:17 dhcp47-74 kernel: [] apic_timer_interrupt+0x70/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [] ? trace_hardirqs_off+0xd/0x10
Oct 18 21:41:17 dhcp47-74 kernel: [] ? acpi_idle_enter_bm+0x227/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [] ? acpi_idle_enter_bm+0x222/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [] cpuidle_idle_call+0x103/0x290
Oct 18 21:41:17 dhcp47-74 kernel: [] cpu_idle+0xe5/0x160
Oct 18 21:41:17 dhcp47-74 kernel: [] rest_init+0xe0/0xf0
Oct 18 21:41:17 dhcp47-74 kernel: [] ? csum_partial_copy_generic+0x170/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [] start_kernel+0x3fc/0x407
Oct 18 21:41:17 dhcp47-74 kernel: [] x86_64_start_reservations+0x131/0x135
Oct 18 21:41:17 dhcp47-74 kernel: [] x86_64_start_kernel+0xed/0xf4
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)Basically what is happening is in xhci_stop_endpoint_command_watchdog()
the xhci->lock is grabbed with just spin_lock. What lockdep deduces is
that if an interrupt occurred while in this function it would deadlock
with xhci_irq because that function also grabs the xhci->lock.Fixing it is trivial by using spin_lock_irqsave instead.
This should be queued to stable kernels as far back as 2.6.33.
Signed-off-by: Don Zickus
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
commit 79c3dd8150fd5236d95766a9e662e3e932b462c9 upstream.
I noticed on my Panther Point system that I wasn't getting hotplug events
for my usb3.0 disk on a usb3 port. I tracked it down to the fact that the
system had the warm reset change bit still set. This seemed to block future
events from being received, including a hotplug event.Clearing this bit during initialization allowed the hotplug event to be
received and the disk to be recognized correctly.This patch should be backported to kernels as old as 2.6.39.
Signed-off-by: Don Zickus
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
commit d31c285b3a71cf9056e6a060de41f37780b0af86 upstream.
Matt's AsMedia xHCI host controller was responding with a Context Error
to an address device command after a configured device reset. Some
sequence of events leads both the slot and endpoint zero add flags
cleared to zero, which the AsMedia host doesn't like:[ 223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context:
[ 223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags
[ 223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags
[ 223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0]
[ 223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1]
[ 223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2]
[ 223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3]
[ 223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4]
[ 223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5]
[ 223.701858] xhci_hcd 0000:03:00.0: Slot Context:
[ 223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info
[ 223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2
[ 223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info
[ 223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state
[ 223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0]
[ 223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1]
[ 223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2]
[ 223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3]
[ 223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context:
[ 223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info
[ 223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2
[ 223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq
[ 223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info
[ 223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0]
[ 223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1]
[ 223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2]
...
[ 223.701927] xhci_hcd 0000:03:00.0: // Ding dong!
[ 223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1.The xHCI spec says that both flags must be set to one for the Address
Device command. When the device is first enumerated,
xhci_setup_addressable_virt_dev() does set those flags. However, when
the device is addressed after it has been reset in the configured state,
xhci_setup_addressable_virt_dev() is not called, and
xhci_copy_ep0_dequeue_into_input_ctx() is called instead. That function
relies on the flags being set up by previous commands, which apparently
isn't a good assumption.Move the setting of the flags into the common parent function.
This should be queued for stable kernels as old as 2.6.35, since that
was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx.Signed-off-by: Sarah Sharp
Tested-by: Matt
Signed-off-by: Greg Kroah-Hartman -
commit 91a13c281d7d4648c0b32dede11a0144c4e7984c upstream.
Patch to fix the error message "directives may not be used inside a macro
argument" which appears when the kernel is compiled for the cris architecture.Signed-off-by: Claudio Scordino
Acked-by: David Rientjes
Signed-off-by: Greg Kroah-Hartman -
commit 161f14191dc166c4e3f37f68af1bc199c6868b7d upstream.
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS
with "platform:"), the platform modalias is prefixed with "platform:".Signed-off-by: Axel Lin
Acked-by: Pratyush Anand
Signed-off-by: Greg Kroah-Hartman -
Backported from commit b95d68b8179764e29558b75cec35ef4a6a98925b.
memset(eld) clears eld->proc_entry which will leak the struct
snd_info_entry when unloading module.Fix it by
- memset only the fields before eld->eld_buffer
- set eld->eld_valid to true _after_ all eld fields have been filledCc: Pierre-louis Bossart
Acked-by: Stephen Warren
Signed-off-by: Wu Fengguang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 1788ea6e3b2a58cf4fb00206e362d9caff8d86a7 upstream.
commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return
from an OPEN call. Prior to that patch, that caused the client to fall
back to doing a normal lookup. When that patch went in, the code began
returning that error to userspace. The d_revalidate codepath however
never had the corresponding change, so it was still possible to end up
with a NULL ctx->state pointer after that.That patch caused a regression. When we attempt to open a directory that
does not have a cached dentry, that open now errors out with EISDIR. If
you attempt the same open with a cached dentry, it will succeed.Fix this by reverting the change in nfs_atomic_lookup and allowing
attempts to open directories to fall back to a normal lookupAlso, add a NFSv4-specific f_ops->open routine that just returns
-ENOTDIR. This should never be called if things are working properly,
but if it ever is, then the dprintk may help in debugging.To facilitate this, a new file_operations field is also added to the
nfs_rpc_ops struct.Signed-off-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 0c73c08ec73dbe080b9ec56696ee21d32754d918 upstream.
For /dev/console case, we do not kill all ldisc users. It's due to
redirected_tty_write test in __tty_hangup. In that case there still
might be a process waiting e.g. in n_tty_read for input.We wait for such processes to disappear. The problem is that we use a
timeout. After this timeout, we continue closing the ldisc and start
freeing tty resources. It obviously leads to crashes when the other
process is woken.So to fix this, we wait infinitely before reiniting the ldisc. (The
tiocsetd remains untouched -- times out after 5s.)This is nicely reproducible with this run from shell:
exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
systemctl stop serial-getty@ttyS0.serviceThe crash proper may be produced only under load or with constified
timing the same as for 92f6fa09b.Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit 300420722e0734a4254f3b634e0f82664495d210 upstream.
It is the only place where reinit is called from. And we really need
to wait for the old ldisc to go once. Actually this is the place where
the waiting originally was (before removed and re-added later).This will make the fix in the following patch easier to implement.
Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit df92d0561de364de53c42abc5d43e04ab6f326a5 upstream.
To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
long for ldisc to be gone. So here we add a parameter to
tty_ldisc_wait_idle to allow that.This is only a preparation for the real fix which is done in the
following patches.Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit c2a3e84f950e7ddba1f3914b005861d46ae60359 upstream.
Reading from the DCC grabs a character from the buffer and
clears the status bit. Since this is a context-changing
operation, instructions following the character read that rely on
the status bit being accurate need to be synchronized with an
ISB.In this case, the status bit check needs to execute after the
character read otherwise we run the risk of reading the character
and checking the status bit before the read can clear the status
bit in the first place. When this happens, the user will see the
same character they typed twice, instead of once.Add an ISB after the read and the write, so that the status check
is synchronized with the read/write operations.Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman -
commit 8249f743f732ccbc3056428945ab1d9bd36d46bf upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit 90f04c2926cfb5bf74533b0a7766bc896f6a0c0e upstream.
Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get
DMA channel resource.setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latencyCAUSE:
Changing mode using setserial command, ".startup" function which gets DMA
channel is called before ".verify_port" function which sets
dma-flag(use_dma/use_dma_flag) as 1.PIO->DMA
.startup: Since dma-flag is 0, DMA channel is not requested.
.verify_port: dma-flag is set as 1.
.shutdown: N/ADMA->PIO
.startup: Since dma-flag is 1, DMA channel is requested.
.verify_port: dma-flag is set as 0.
.shutdown: Since dma-flag is 0, DMA channel is not released.This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.MODIFICATION:
Currently, when release DMA channel resource, this driver checks dma-flag.
However, this specification occurs the above issue.
This driver must check whether dma_request_channel is executed or not.
The values are saved in private data variable "chan_tx/chan_tx".
These variables mean if the value is NULL, DMA channel is not requested,
if not NULL, DMA channel is requested.This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit a1d7cfe29f13cf45f8094929864b9c66bf0cd91b upstream.
Using hardware flow control,
currently, register of the control-bit(AFE) is not set.
This patch fixes the issue.Signed-off-by: Tomoya MORINAGA
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
commit 2a9887919457c6e1bd482e8448223be59d19010a upstream.
ISSUE:
Using ML7831, MAC address writing doesn't work well.CAUSE:
ML7831 and EG20T have the same register map for MAC address access.
However, this driver processes the writing the same as ML7223.
This is not true.
This driver must process the writing the same as EG20T.
This patch fixes the issue.Signed-off-by: Tomoya MORINAGA
Cc: Masayuki Ohtak
Cc: Alexander Stein
Cc: Denis Turischev
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
commit 584ad00ce4bfe594e4c4a89944b3c635187a1ca1 upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA
Signed-off-by: Greg Kroah-Hartman -
commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 upstream.
There may be an issue when the user issue "reboot/shutdown" command, then
the device has shut down its hardware, after that, this runtime-pm featured
device's driver will probably be scheduled to do its suspend routine,
and at its suspend routine, it may access hardware, but the device has
already shutdown physically, then the system hang may be occurred.I ran out this issue using an auto-suspend supported USB devices, like
3G modem, keyboard. The usb runtime suspend routine may be scheduled
after the usb controller has been shut down, and the usb runtime suspend
routine will try to suspend its roothub(controller), it will access
register, then the system hang occurs as the controller is shutdown.Signed-off-by: Peter Chen
Acked-by: Ming Lei
Acked-by: Greg Kroah-Hartman
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 731abb9cb27aef6013ce60808a04e04a545f3f4e upstream.
Commit 1c5cae815d removed an explicit call to dev_alloc_name in ip6_tnl_create
because register_netdevice will now create a valid name. This works for the
net_device itself.However the tunnel keeps a copy of the name in the parms structure for the
ip6_tnl associated with the tunnel. parms.name is set by copying the net_device
name in ip6_tnl_dev_init_gen. That function is called from ip6_tnl_dev_init in
ip6_tnl_create, but it is done before register_netdevice is called so the name
is set to a bogus value in the parms.name structure.This shows up if you do a simple tunnel add, followed by a tunnel show:
[root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200
[root@localhost ~]# ip -6 tunnel show
ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
[root@localhost ~]#Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after
register_netdevice has successfully returned.Signed-off-by: Josh Boyer
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
