- 09 Jul, 2014 40 commits
-
-
Johan Hedberg authored
commit c73f94b8 upstream. The SMP code expects hdev to be unlocked since e.g. crypto functions will try to (re)lock it. Therefore, we need to release the lock before calling into smp.c from mgmt.c. Without this we risk a deadlock whenever the smp_user_confirm_reply() function is called. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Tested-by:
Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hedberg authored
commit 50143a43 upstream. When inquiry is canceled through the HCI_Cancel_Inquiry command there is no Inquiry Complete event generated. Instead, all we get is the command complete for the HCI_Inquiry_Cancel command. This means that we must call the hci_discovery_set_state() function from the respective command complete handler in order to ensure that user space knows the correct discovery state. Signed-off-by:
-
Johan Hedberg authored
commit e694788d upstream. The conn->link_key variable tracks the type of link key in use. It is set whenever we respond to a link key request as well as when we get a link key notification event. These two events do not however always guarantee that encryption is enabled: getting a link key request and responding to it may only mean that the remote side has requested authentication but not encryption. On the other hand, the encrypt change event is a certain guarantee that encryption is enabled. The real encryption state is already tracked in the conn->link_mode variable through the HCI_LM_ENCRYPT bit. This patch fixes a check for encryption in the hci_conn_auth function to use the proper conn->link_mode value and thereby eliminates the chance of a false positive result. Signed-off-by:
-
Johan Hedberg authored
commit ba15a58b upstream. From the Bluetooth Core Specification 4.1 page 1958: "if both devices have set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for all just-works cases regardless of the MITM requirements, however following the specification to the word means that we should not be doing confirmation when neither side has the MITM flag set. Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
-
Thomas Hellstrom authored
commit 4e578080 upstream. Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: Christopher Friedt <chrisfriedt@gmail.com> Tested-by:
Christopher Friedt <chrisfriedt@gmail.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
-
Jani Nikula authored
commit 2e7eeeb5 upstream. For reasons I can't claim to fully understand gen4 seems to require backlight duty cycle setting after the backlight has been enabled, or else black screen follows. I don't have documentation for the correct sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1. This fixes a regression introduced by commit b35684b8 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:13:41 2013 +0200 drm/i915: do full backlight setup at enable time Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791 Reported-and-tested-by: mcy@lm7.fr Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423Reported-and-tested-by:
Marc Milgram <mmilgram@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 2b85886a upstream. On certain platforms pixel_multiplier is read out in .get_pipe_config(), but it also gets used to calculate the pixel clock in intel_sdvo_get_config(). If the pipe is disable but some SDVO outputs are active, we may end up dividing by zero in intel_sdvo_get_config(). To avoid the problem simply check for zero pixel_multiplier and skip the division. Another attempt at fixing this involved populating pixel_multiplier to 1 even for disabled pipes, but that triggered a WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus encoder_pixel_multiplier was left at zero and didn't match pipe_config->pixel_multiplier. The "divide by pixel_multiplier" operation got introduced here: commit 18442d08 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over and it has caused a regression on certain machines since they would hit the div-by-zero during resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520Tested-by:
Tim Richardson <tim@tim-richardson.net> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ilia Mirkin authored
commit 255b329c upstream. This fixes hangs on GK208 which happen instantaneously on trying to use a geometry shader. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Mario Kleiner authored
commit dcfb1009 upstream. Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was responsible for calling both, the vblank-irq handler (display engine irq) and kms-pageflip completion handler (from fifo irq), the order of invocation was wrong. nouveau_finish_flip() was called before drm_handle_vblank() for the vblank of pageflip completion, so the emitted pageflip event contained stale vblank count and timestamp from previous vblank. This caused failure in userspace to timestamp properly. Reorder order of invocation of engine irq handlers: Put NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO, so that drm_handle_vblank() gets called to update vblank timestamps and count before potential pageflip events make use of that information. This works on nv-50 and later, where kms-pageflip completion triggers an irq either after a separate vblank irq, or both pageflip and vblank trigger one common irq invocation, but never before vblank irqs. v2 (Ben): - removed mods for nv04-nv40, it doesn't help there anyway - this is considered a hack, and a better solution should be found Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit b397207b upstream. Volatile bit was in the wrong location. This bit is not used at the moment. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit b0880e87 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Noticed by: Dieter Nützel <Dieter@nuetzel-hh.de> Signed-off-by:
-
Alex Deucher authored
commit e0792981 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 Possibly also fixes: https://bugzilla.kernel.org/show_bug.cgi?id=68571Noticed-by:
Jonathan Howard <jonathan@unbiased.name> Signed-off-by:
-
Marek Olšák authored
commit ec65da38 upstream. It hangs the hardware. Signed-off-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 64252835 upstream. We need to specify the encoder mode as LVDS for eDP when using the Crtc_Source atom table in order to properly set up the FMT hardware. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73911Signed-off-by:
-
Alex Deucher authored
commit 3b6d9fd2 upstream. Only DCE5+ asics support DP 1.2. Noticed by ArtForz on IRC. Signed-off-by:
-
Alex Deucher authored
commit af5d3653 upstream. We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by:
-
Alex Deucher authored
commit 7d5ab300 upstream. May fix display issues with non-HDMI displays. Signed-off-by:
-
Mario Kleiner authored
commit ba124a41 upstream. Need to drm_vblank_get/put() the crtc involved in a pending pageflip, or we might not get vblank irqs and updates of vblank counts and timestamps for pageflip events and flip completion. Signed-off-by:
-
Mario Kleiner authored
commit e291af3f upstream. nv04_disp_scanoutpos() must abort to trigger simple timestamping fallback if vtotal/htotal regs return zero. This happens if the output isn't a digital output, but a vga analog output, as the regs don't get initialized in that case. Fixes timestamping failure on nv-40 and earlier with vga output. Signed-off-by:
-
Mario Kleiner authored
commit af4870e4 upstream. Cards with nv04 display engine can't reliably use vblank counts and timestamps computed via drm_handle_vblank(), as the function gets invoked after sending the pageflip events. Fix this by defaulting to the old crtcid = -1 fallback path on <= NV-50 cards, and only using the precise path on NV-50 and later. Signed-off-by:
-
Alex Deucher authored
commit f2bc5616 upstream. Avoids blank screens on muxed systems when runpm is active. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75917Signed-off-by:
-
Thomas Petazzoni authored
commit b7e46062 upstream. The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl() to access I/O registers. However, those functions do not do any endianness swapping, which means that they won't work when the CPU runs in big-endian but the I/O registers are little endian, which is the common situation for ARM systems running big endian. Since __raw_writel() and __raw_readl() do not include any memory barriers and the pxa3xx_nand driver can only be compiled for ARM platforms, the closest I/o accessors functions that do endianess swapping are writel_relaxed() and readl_relaxed(). This patch has been verified to work on Armada XP GP: without the patch, the NAND is not detected when the kernel runs big endian while it is properly detected when the kernel runs little endian. With the patch applied, the NAND is properly detected in both situations (little and big endian). Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
pekon gupta authored
commit f306e8c3 upstream. fixes: commit 62116e51 mtd: nand: omap2: Support for hardware BCH error correction. In omap_elm_correct_data(), if bitflip_count in an erased-page is within the correctable limit (< ecc.strength), then it is not indicated back to the caller ecc->read_page(). This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as perfectly clean and use it for writing even if actual bitflip_count was dangerously high (bitflip_count > mtd->bitflip_threshold). This patch fixes this above issue, by returning 'stats' to caller ecc->read_page() under all scenarios. Reported-by:
Pekon Gupta <pekon@ti.com> Signed-off-by:
-
Pekon Gupta authored
commit f034d87d upstream. As subpage write is enabled by default for all drivers, nand_write_subpage_hwecc causes a crash if the driver did not register ecc->hwctl or ecc->calculate. This behavior was introduced in commit 837a6ba4 "mtd: nand: subpage write support for hardware based ECC schemes". This fixes a crash by emulating subpage write support by padding sub-page data with 0xff on either sides to make it full page compatible. Reported-by:
Helmut Schaa <helmut.schaa@googlemail.com> Tested-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 616a8394 upstream. As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5f, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f ("rt2x00: Fix rfkill_polling register function.") Bisected-by:
Niels <nille0386@googlemail.com> Reported-and-tested-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 8edcb0ba upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 <snip> [ 860.827280] Call Trace: [ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66 [ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55 [ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0 [ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70 [ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0 [ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70 [ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20 [ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110 [ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by:
Peter Wu <lekensteyn@gmail.com> Reported-and-tested-by:
Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Michal Nazarewicz authored
commit f0688c8b upstream. If the descriptors do not need any strings and user space sends empty set of strings, the ffs->stringtabs field remains NULL. Thus *ffs->stringtabs in functionfs_bind leads to a NULL pointer dereferenece. The bug was introduced by commit [fd7c9a00: “use usb_string_ids_n()”]. While at it, remove double initialisation of lang local variable in that function. ffs->strings_count does not need to be checked in any way since in the above scenario it will remain zero and usb_string_ids_n() is a no-operation when colled with 0 argument. Signed-off-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Michal Nazarewicz authored
commit 09122141 upstream. Even though usb_functionfs_descs_head structure is now deprecated, it has been used by some user space tools. Its removel in commit [ac8dde11: “Add flags to descriptors block”] was an oversight leading to build breakage for such tools. Bring it back so that old user space tools can still be build without problems on newer kernel versions. Reported-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Reported-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
-
Johan Hovold authored
commit aea1ae87 upstream. Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28ba ("USB: ftdi_sio: fix hi-speed device packet size calculation") Reported-by:
Mike Remski <mremski@mutualink.net> Tested-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Peter Chen authored
commit e4adcff0 upstream. We need to delete un-finished td from current request's td list at ep_dequeue API, otherwise, this non-user td will be remained at td list before this request is freed. So if we do ep_queue-> ep_dequeue->ep_queue sequence, when the complete interrupt for the second ep_queue comes, we search td list for this request, the first td (added by the first ep_queue) will be handled, and its status is still active, so we will consider the this transfer still not be completed, but in fact, it has completed. It causes the peripheral side considers it never receives current data for this transfer. We met this problem when do "Error Recovery Test - Device Configured" test item for USBCV2 MSC test, the host has never received ACK for the IN token for CSW due to peripheral considers it does not get this CBW, the USBCV test log like belows: -------------------------------------------------------------------------- INFO Issuing BOT MSC Reset, reset should always succeed INFO Retrieving status on CBW endpoint INFO CBW endpoint status = 0x0 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x0 INFO Issuing required command (Test Unit Ready) to verify device has recovered INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW Bulk Request timed out! ERROR Failed CSW phase : should have been success or stall FAIL (5.3.4) The CSW status value must be 0x00, 0x01, or 0x02. ERROR BOTCommonMSCRequest failed: error=80004000 Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Ezequiel Garcia authored
commit 7adb5c87 upstream. At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = de11c000 [0000008c] *pgd=9e174831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-00001-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [<c0327798>] lr : [<c0327794>] psr: a0000013 sp : de123df8 ip : 00000004 fp : 00028f00 r10: 00000000 r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 00000015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 60000013 bf043650 000012fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: 00000000 bf059000 a0000013 c02c5bc0 00000000 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 00000000 3f40: 00000800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 00000001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 00000081 60000010 00028e70 00028e70 00028ea4 3fa0: 00000081 c000e500 00028e70 00028e70 00028ea4 00000800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 00000081 00000001 00000001 00000000 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 60000010 00028ea4 00000000 00000000 [<c0327798>] (am335x_shutdown) from [<bf054488>] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [<bf054488>] (dsps_musb_exit [musb_dsps]) from [<bf043650>] (musb_shutdown+0x80/0x90 [musb_hdrc]) [<bf043650>] (musb_shutdown [musb_hdrc]) from [<bf043a20>] (musb_remove+0x24/0x68 [musb_hdrc]) [<bf043a20>] (musb_remove [musb_hdrc]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02ca838>] (platform_device_del+0x14/0x9c) [<c02ca838>] (platform_device_del) from [<c02ca8cc>] (platform_device_unregister+0xc/0x20) [<c02ca8cc>] (platform_device_unregister) from [<bf054194>] (dsps_remove+0x18/0x38 [musb_dsps]) [<bf054194>] (dsps_remove [musb_dsps]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c8e28>] (device_release_driver+0x20/0x2c) [<c02c8e28>] (device_release_driver) from [<c02c884c>] (bus_remove_device+0xdc/0x10c) [<c02c884c>] (bus_remove_device) from [<c02c5b20>] (device_del+0x104/0x198) [<c02c5b20>] (device_del) from [<c02c5bc0>] (device_unregister+0xc/0x20) [<c02c5bc0>] (device_unregister) from [<bf05900c>] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [<bf05900c>] (of_remove_populated_child [musb_am335x]) from [<c02c5c48>] (device_for_each_child+0x44/0x70) [<c02c5c48>] (device_for_each_child) from [<bf05902c>] (am335x_child_remove+0x18/0x30 [musb_am335x]) [<bf05902c>] (am335x_child_remove [musb_am335x]) from [<c02ca37c>] (platform_drv_remove+0x18/0x1c) [<c02ca37c>] (platform_drv_remove) from [<c02c8db0>] (__device_release_driver+0x70/0xc8) [<c02c8db0>] (__device_release_driver) from [<c02c94c8>] (driver_detach+0xb4/0xb8) [<c02c94c8>] (driver_detach) from [<c02c8ab4>] (bus_remove_driver+0x4c/0xa0) [<c02c8ab4>] (bus_remove_driver) from [<c007fc40>] (SyS_delete_module+0x128/0x1cc) [<c007fc40>] (SyS_delete_module) from [<c000e500>] (ret_fast_syscall+0x0/0x48) Fixes: 97238b35 ("usb: musb: dsps: use proper child nodes") Acked-by:
George Cherian <george.cherian@ti.com> Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Thomas Gleixner authored
commit c58d80f5 upstream. Some TI chips raise the DMA complete interrupt before the actual transfer has been completed. The code tries to busy wait for a few microseconds and if that fails it arms an hrtimer to recheck. So far so good, but that has the following issue: CPU 0 CPU1 start_next_transfer(RQ1); DMA interrupt if (premature_irq(RQ1)) if (!hrtimer_active(timer)) hrtimer_start(timer); hrtimer expires timer->state = CALLBACK_RUNNING; timer->fn() cppi41_recheck_tx_req() complete_request(RQ1); if (requests_pending()) start_next_transfer(RQ2); DMA interrupt if (premature_irq(RQ2)) if (!hrtimer_active(timer)) hrtimer_start(timer); timer->state = INACTIVE; The premature interrupt of request2 on CPU1 does not arm the timer and therefor the request completion never happens because it checks for !hrtimer_active(). hrtimer_active() evaluates: timer->state != HRTIMER_STATE_INACTIVE which of course evaluates to true in the above case as timer->state is CALLBACK_RUNNING. That's clearly documented: * A timer is active, when it is enqueued into the rbtree or the * callback function is running or it's in the state of being migrated * to another cpu. But that's not what the code wants to check. The code wants to check whether the timer is queued, i.e. whether its armed and waiting for expiry. We have a helper function for this: hrtimer_is_queued(). This evaluates: timer->state & HRTIMER_STATE_QUEUED So in the above case this evaluates to false and therefor forces the DMA interrupt on CPU1 to call hrtimer_start(). Use hrtimer_is_queued() instead of hrtimer_active() and evrything is good. Reported-by:
Torben Hohn <torbenh@linutronix.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Linus Walleij authored
commit 82363cf2 upstream. There is a regression in the upcoming v3.16-rc1, that is caused by a problem that has been around for a while but now finally hangs the system. The bootcrawl looks like this: pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22 pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik musb-hdrc musb-hdrc.0.auto: Error applying setting, reverse things back HS USB OTG: no transceiver configured musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral (...) The ux500 MUSB driver propagates the OF node to the dynamically created musb-hdrc device, which is incorrect as it makes the OF core believe there are two devices spun from the very same DT node, which confuses other parts of the device core, notably the pin control subsystem, which will try to apply all the pin control settings also to the HDRC device as it gets instantiated. (The OMAP2430 for example, does not set the of_node member.) Cc: Arnd Bergmann <arnd@arndb.de> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Bjørn Mork authored
commit b0ebef36 upstream. Adding a couple of Olivetti modems and blacklisting the net function on a couple which are already supported. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Oliver Neukum authored
commit 1cab4c68 upstream. Reported by Alif Mubarak Ahmad: This device vendor and product id is 1c9e:9800 It is working as serial interface with generic usbserial driver. I thought it is more suitable to use usbserial option driver, which has better capability distinguishing between modem serial interface and micro sd storage interface. [ johan: style changes ] Signed-off-by:
Oliver Neukum <oneukum@suse.de> Tested-by:
Alif Mubarak Ahmad <alive4ever@live.com> Signed-off-by:
-
Wang, Yu authored
commit d6236f6d upstream. The system suspend flow as following: 1, Freeze all user processes and kenrel threads. 2, Try to suspend all devices. 2.1, If pci device is in RPM suspended state, then pci driver will try to resume it to RPM active state in the prepare stage. 2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two workqueue items to resume usb2&usb3 roothub devices. 2.3, Call suspend callbacks of devices. 2.3.1, All suspend callbacks of all hcd's children, including roothub devices are called. 2.3.2, Finally, hcd_pci_suspend callback is called. Due to workqueue threads were already frozen in step 1, the workqueue items can't be scheduled, and the roothub devices can't be resumed in this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in usb_hcd_resume_root_hub won't be cleared. Finally, hcd_pci_suspend will return -EBUSY, and system suspend fails. The reason why this issue doesn't show up very often is due to that choose_wakeup will be called in step 2.3.1. In step 2.3.1, if udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then udev will resume to RPM active for changing the wakeup settings. This has been a lucky hit which hides this issue. For some special xHCI controllers which have no USB2 port, then roothub will not match hub driver due to probe failed. Then its do_remote_wakeup will be set to zero, and we won't be as lucky. xhci driver doesn't need to resume roothub devices everytime like in the above case. It's only needed when there are pending event TRBs. This patch should be back-ported to kernels as old as 3.2, that contains the commit f69e3120 "USB: XHCI: resume root hubs when the controller resumes" Signed-off-by:
Wang, Yu <yu.y.wang@intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> [use readl() instead of removed xhci_readl(), reword commit message -Mathias] Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 3213b151 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e33 "xhci 1.0: Set transfer burst count field." Suggested-by:
ShiChun Ma <masc2008@qq.com> Signed-off-by:
-
Mathias Nyman authored
commit 6fcfb0d6 upstream. Command completion events normally include command completion status, SLOT_ID, and a pointer to the original command. Reset device command completion SLOT_ID may be zero according to xhci specs 4.6.11. VIA controllers set the SLOT_ID to zero, triggering a WARN_ON in the command completion handler. Use the SLOT ID found from the original command instead. This patch should be applied to stable kernels since 3.13 that contain the commit 20e7acb1 "xhci: use completion event's slot id rather than dig it out of command" Reported-by:
Saran Neti <sarannmr@gmail.com> Tested-by:
-
Paolo Bonzini authored
commit 8faeb529 upstream. Even though the virtio-scsi spec guarantees that all requests related to the TMF will have been completed by the time the TMF itself completes, the request queue's callback might not have run yet. This causes requests to be completed more than once, and as a result triggers a variety of BUGs or oopses. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
Venkatesh Srinivas <venkateshs@google.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Ulrich Obergfell authored
commit 8922a908 upstream. After scsi_try_to_abort_cmd returns, the eh_abort_handler may have already found that the command has completed in the device, causing the host_byte to be nonzero (e.g. it could be DID_ABORT). When this happens, ORing DID_TIME_OUT into the host byte will corrupt the result field and initiate an unwanted command retry. Fix this by using set_host_byte instead, following the model of commit 2082ebc4. Signed-off-by:
Ulrich Obergfell <uobergfe@redhat.com> [Fix all instances according to review comments. - Paolo] Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
