1. 23 Mar, 2015 23 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix built-in mic on Compaq Presario CQ60 · 6ec5020f
      Takashi Iwai authored
      commit ddb6ca75 upstream.
      
      Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
      built-in mic NID 0x17 instead of NID 0x1d, and it results in the
      non-working mic.  This patch just remaps the pin correctly via fixup.
      
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6ec5020f
    • Jan Beulich's avatar
      xen-pciback: limit guest control of command register · e321556c
      Jan Beulich authored
      commit af6fc858 upstream.
      
      Otherwise the guest can abuse that control to cause e.g. PCIe
      Unsupported Request responses by disabling memory and/or I/O decoding
      and subsequently causing (CPU side) accesses to the respective address
      ranges, which (depending on system configuration) may be fatal to the
      host.
      
      Note that to alter any of the bits collected together as
      PCI_COMMAND_GUEST permissive mode is now required to be enabled
      globally or on the specific device.
      
      This is CVE-2015-2150 / XSA-120.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e321556c
    • Christian König's avatar
      drm/radeon: drop setting UPLL to sleep mode · ff37ae6a
      Christian König authored
      commit a17d4996 upstream.
      
      Just keep it working, seems to fix some PLL problems.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ff37ae6a
    • Peter Chen's avatar
      ARM: imx6sl-evk: set swbst_reg as vbus's parent reg · 410ac5d8
      Peter Chen authored
      commit 2de9dd03 upstream.
      
      USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
      parent reg, it fixed a bug that the voltage of vbus is incorrect
      due to swbst_reg is disabled after boots up.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      410ac5d8
    • Peter Chen's avatar
      ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg · 4a3082e1
      Peter Chen authored
      commit 40f73779 upstream.
      
      USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
      parent reg, it fixed a bug that the voltage of vbus is incorrect
      due to swbst_reg is disabled after boots up.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4a3082e1
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled · 297c2311
      Steven Rostedt (Red Hat) authored
      commit 524a3868 upstream.
      
      Some archs (specifically PowerPC), are sensitive with the ordering of
      the enabling of the calls to function tracing and setting of the
      function to use to be traced.
      
      That is, update_ftrace_function() sets what function the ftrace_caller
      trampoline should call. Some archs require this to be set before
      calling ftrace_run_update_code().
      
      Another bug was discovered, that ftrace_startup_sysctl() called
      ftrace_run_update_code() directly. If the function the ftrace_caller
      trampoline changes, then it will not be updated. Instead a call
      to ftrace_startup_enable() should be called because it tests to see
      if the callback changed since the code was disabled, and will
      tell the arch to update appropriately. Most archs do not need this
      notification, but PowerPC does.
      
      The problem could be seen by the following commands:
      
       # echo 0 > /proc/sys/kernel/ftrace_enabled
       # echo function > /sys/kernel/debug/tracing/current_tracer
       # echo 1 > /proc/sys/kernel/ftrace_enabled
       # cat /sys/kernel/debug/tracing/trace
      
      The trace will show that function tracing was not active.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      297c2311
    • Pratyush Anand's avatar
      ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl · 729ea71c
      Pratyush Anand authored
      commit 1619dc3f upstream.
      
      When ftrace is enabled globally through the proc interface, we must check if
      ftrace_graph_active is set. If it is set, then we should also pass the
      FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
      ftrace is disabled globally through the proc interface, we must check if
      ftrace_graph_active is set. If it is set, then we should also pass the
      FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().
      
      Consider the following situation.
      
       # echo 0 > /proc/sys/kernel/ftrace_enabled
      
      After this ftrace_enabled = 0.
      
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
      
      Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
      called.
      
       # echo 1 > /proc/sys/kernel/ftrace_enabled
      
      Now ftrace_enabled will be set to true, but still
      ftrace_enable_ftrace_graph_caller() will not be called, which is not
      desired.
      
      Further if we execute the following after this:
        # echo nop > /sys/kernel/debug/tracing/current_tracer
      
      Now since ftrace_enabled is set it will call
      ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
      the ARM platform.
      
      On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
      it checks whether the old instruction is a nop or not. If it's not a nop,
      then it returns an error. If it is a nop then it replaces instruction at
      that address with a branch to ftrace_graph_caller.
      ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
      if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
      or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
      then it will return an error, which will cause the generic ftrace code to
      raise a warning.
      
      Note, x86 does not have an issue with this because the architecture
      specific code for ftrace_enable_ftrace_graph_caller() and
      ftrace_disable_ftrace_graph_caller() does not check the previous state,
      and calling either of these functions twice in a row has no ill effect.
      
      Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.comSigned-off-by: default avatarPratyush Anand <panand@redhat.com>
      [
        removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
        if CONFIG_FUNCTION_GRAPH_TRACER is not set.
      ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      729ea71c
    • Ahmed S. Darwish's avatar
      can: kvaser_usb: Read all messages in a bulk-in URB buffer · d5da6576
      Ahmed S. Darwish authored
      commit 2fec5104 upstream.
      
      The Kvaser firmware can only read and write messages that are
      not crossing the USB endpoint's wMaxPacketSize boundary. While
      receiving commands from the CAN device, if the next command in
      the same URB buffer crossed that max packet size boundary, the
      firmware puts a zero-length placeholder command in its place
      then moves the real command to the next boundary mark.
      
      The driver did not recognize such behavior, leading to missing
      a good number of rx events during a heavy rx load session.
      
      Moreover, a tx URB context only gets freed upon receiving its
      respective tx ACK event. Over time, the free tx URB contexts
      pool gets depleted due to the missing ACK events. Consequently,
      the netif transmission queue gets __permanently__ stopped; no
      frames could be sent again except after restarting the CAN
      newtwork interface.
      Signed-off-by: default avatarAhmed S. Darwish <ahmed.darwish@valeo.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d5da6576
    • Ahmed S. Darwish's avatar
      can: kvaser_usb: Avoid double free on URB submission failures · 8c27234f
      Ahmed S. Darwish authored
      commit deb2701c upstream.
      
      Upon a URB submission failure, the driver calls usb_free_urb()
      but then manually frees the URB buffer by itself.  Meanwhile
      usb_free_urb() has alredy freed out that transfer buffer since
      we're the only code path holding a reference to this URB.
      
      Remove two of such invalid manual free().
      Signed-off-by: default avatarAhmed S. Darwish <ahmed.darwish@valeo.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8c27234f
    • Oliver Hartkopp's avatar
      can: add missing initialisations in CAN related skbuffs · 96336fb9
      Oliver Hartkopp authored
      commit 96943901 upstream.
      
      When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
      this can lead to a skb_under_panic due to missing skb initialisations.
      
      Add the missing initialisations at the CAN skbuff creation times on driver
      level (rx path) and in the network layer (tx path).
      Reported-by: default avatarAustin Schuh <austin@peloton-tech.com>
      Reported-by: default avatarDaniel Steer <daniel.steer@mclaren.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      96336fb9
    • Takashi Iwai's avatar
      ALSA: hda - Fix regression of HD-audio controller fallback modes · 77198b34
      Takashi Iwai authored
      commit a1f3f1ca upstream.
      
      The commit [63e51fd7: ALSA: hda - Don't take unresponsive D3
      transition too serious] introduced a conditional fallback behavior to
      the HD-audio controller depending on the flag set.  However, it
      introduced a silly bug, too, that the flag was evaluated in a reverse
      way.  This resulted in a regression of HD-audio controller driver
      where it can't go to the fallback mode at communication errors.
      
      Unfortunately (or fortunately?) this didn't come up until recently
      because the affected code path is an error handling that happens only
      on an unstable hardware chip.  Most of recent chips work stably, thus
      they didn't hit this problem.  Now, we've got a regression report with
      a VIA chip, and this seems indeed requiring the fallback to the
      polling mode, and finally the bug was revealed.
      
      The fix is a oneliner to remove the wrong logical NOT in the check.
      (Lesson learned - be careful about double negation.)
      
      The bug should be backported to stable, but the patch won't be
      applicable to 3.13 or earlier because of the code splits.  The stable
      fix patches for earlier kernels will be posted later manually.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
      Fixes: 63e51fd7 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      77198b34
    • Maxime Ripard's avatar
      irqchip: armada-370-xp: Fix chained per-cpu interrupts · 5a8b9eaa
      Maxime Ripard authored
      commit 5724be84 upstream.
      
      On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
      controller. Yet, it still has to handle some per-cpu interrupt.
      
      To do so, it is chained with the GIC using a per-cpu interrupt. However, the
      current code only call irq_set_chained_handler, which is called and enable that
      interrupt only on the boot CPU, which means that the parent per-CPU interrupt
      is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
      actually work as expected.
      
      This was not seen until now since the only MPIC PPI users were the Marvell
      timers that were not working, but not used either since the system use the ARM
      TWD by default, and the ethernet controllers, that are faking there interrupts
      as SPI, and don't really expect to have interrupts on the secondary cores
      anyway.
      
      Add a CPU notifier that will enable the PPI on the secondary cores when they
      are brought up.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.comSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5a8b9eaa
    • James Bottomley's avatar
      libsas: Fix Kernel Crash in smp_execute_task · 742275d4
      James Bottomley authored
      commit 6302ce4d upstream.
      
      This crash was reported:
      
      [  366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
      [  368.804046] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804098] PGD 0
      [  368.804114] Oops: 0002 [#1] SMP
      [  368.804143] CPU 1
      [  368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
      [  368.804749]
      [  368.804764] Pid: 392, comm: kworker/u:3 Tainted: P        W  O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
      [  368.804802] RIP: 0010:[<ffffffff81358457>]  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804827] RSP: 0018:ffff880117001cc0  EFLAGS: 00010246
      [  368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420
      [  368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4
      [  368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe
      [  368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4
      [  368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8
      [  368.804916] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
      [  368.804931] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0
      [  368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0)
      [  368.805009] Stack:
      [  368.805017]  ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
      [  368.805062]  000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
      [  368.805100]  ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
      [  368.805135] Call Trace:
      [  368.805153]  [<ffffffff81056f7c>] ? up+0xb/0x33
      [  368.805168]  [<ffffffff813583ac>] ? mutex_lock+0x16/0x25
      [  368.805194]  [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
      [  368.805217]  [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
      [  368.805240]  [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
      [  368.805264]  [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
      [  368.805280]  [<ffffffff81355a2a>] ? printk+0x43/0x48
      [  368.805296]  [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
      [  368.805318]  [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
      [  368.805336]  [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
      [  368.805351]  [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
      [  368.805366]  [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
      [  368.805382]  [<ffffffff81052c4e>] ? kthread+0x79/0x81
      [  368.805399]  [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
      [  368.805416]  [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
      [  368.805431]  [<ffffffff8135fea0>] ? gs_change+0x13/0x13
      [  368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
      [  368.805851] RIP  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.805877]  RSP <ffff880117001cc0>
      [  368.805886] CR2: 0000000000000000
      [  368.805899] ---[ end trace b720682065d8f4cc ]---
      
      It's directly caused by 89d3cf6a [SCSI] libsas: add mutex for SMP task
      execution, but shows a deeper cause: expander functions expect to be able to
      cast to and treat domain devices as expanders.  The correct fix is to only do
      expander discover when we know we've got an expander device to avoid wrongly
      casting a non-expander device.
      Reported-by: default avatarPraveen Murali <pmurali@logicube.com>
      Tested-by: default avatarPraveen Murali <pmurali@logicube.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      742275d4
    • jmlatten@linux.vnet.ibm.com's avatar
      tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send · 690f544a
      jmlatten@linux.vnet.ibm.com authored
      commit 62dfd912 upstream.
      
      Problem: When IMA and VTPM are both enabled in kernel config,
      kernel hangs during bootup on LE OS.
      
      Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
      and tpm_ibmtpm_recv getting called. A trace showed that
      tpm_ibmtpm_recv was hanging.
      
      Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
      was sending CRQ message that probably did not make much sense
      to phype because of Endianness. The fix below sends correctly
      converted CRQ for LE. This was not caught before because it
      seems IMA is not enabled by default in kernel config and
      IMA exercises this particular code path in vtpm.
      
      Tested with IMA and VTPM enabled in kernel config and VTPM
      enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
      CRQ and TPM command code paths in vtpm.
      Patch is against Peter's tpmdd tree on github which included
      Vicky's previous vtpm le patches.
      Signed-off-by: default avatarJoy Latten <jmlatten@linux.vnet.ibm.com>
      Reviewed-by: default avatarAshley Lai <ashley@ahsleylai.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      690f544a
    • Alexander Sverdlin's avatar
      spi: pl022: Fix race in giveback() leading to driver lock-up · b973ad9a
      Alexander Sverdlin authored
      commit cd6fa8d2 upstream.
      
      Commit fd316941 ("spi/pl022: disable port when unused") introduced a race,
      which leads to possible driver lock up (easily reproducible on SMP).
      
      The problem happens in giveback() function where the completion of the transfer
      is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
      transfer might be setup in between, which brings driver in locked-up state.
      
      Exact event sequence on SMP:
      
      core0                                   core1
      
                                              => pump_transfers()
                                              /* message->state == STATE_DONE */
                                                => giveback()
                                                  => spi_finalize_current_message()
      
      => pl022_unprepare_transfer_hardware()
      => pl022_transfer_one_message
        => flush()
        => do_interrupt_dma_transfer()
          => set_up_next_transfer()
          /* Enable SSP, turn on interrupts */
          writew((readw(SSP_CR1(pl022->virtbase)) |
                 SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));
      
      ...
      
      => pl022_interrupt_handler()
        => readwriter()
      
                                              /* disable the SPI/SSP operation */
                                              => writew((readw(SSP_CR1(pl022->virtbase)) &
                                                        (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));
      
      Lockup! SPI controller is disabled and the data will never be received. Whole
      SPI subsystem is waiting for transfer ACK and blocked.
      
      So, only signal transfer completion after disabling the controller.
      
      Fixes: fd316941 (spi/pl022: disable port when unused)
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b973ad9a
    • Juergen Gross's avatar
      xen/events: avoid NULL pointer dereference in dom0 on large machines · a922ccc2
      Juergen Gross authored
      commit 85e40b05 upstream.
      
      Using the pvops kernel a NULL pointer dereference was detected on a
      large machine (144 processors) when booting as dom0 in
      evtchn_fifo_unmask() during assignment of a pirq.
      
      The event channel in question was the first to need a new entry in
      event_array[] in events_fifo.c. Unfortunately xen_irq_info_pirq_setup()
      is called with evtchn being 0 for a new pirq and the real event channel
      number is assigned to the pirq only during __startup_pirq().
      
      It is mandatory to call xen_evtchn_port_setup() after assigning the
      event channel number to the pirq to make sure all memory needed for the
      event channel is allocated.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a922ccc2
    • Brian King's avatar
      bnx2x: Force fundamental reset for EEH recovery · ef3112c8
      Brian King authored
      commit da293700 upstream.
      
      EEH recovery for bnx2x based adapters is not reliable on all Power
      systems using the default hot reset, which can result in an
      unrecoverable EEH error. Forcing the use of fundamental reset
      during EEH recovery fixes this.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ef3112c8
    • Tejun Heo's avatar
      workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE · 1264f1e3
      Tejun Heo authored
      commit 8603e1b3 upstream.
      
      cancel[_delayed]_work_sync() are implemented using
      __cancel_work_timer() which grabs the PENDING bit using
      try_to_grab_pending() and then flushes the work item with PENDING set
      to prevent the on-going execution of the work item from requeueing
      itself.
      
      try_to_grab_pending() can always grab PENDING bit without blocking
      except when someone else is doing the above flushing during
      cancelation.  In that case, try_to_grab_pending() returns -ENOENT.  In
      this case, __cancel_work_timer() currently invokes flush_work().  The
      assumption is that the completion of the work item is what the other
      canceling task would be waiting for too and thus waiting for the same
      condition and retrying should allow forward progress without excessive
      busy looping
      
      Unfortunately, this doesn't work if preemption is disabled or the
      latter task has real time priority.  Let's say task A just got woken
      up from flush_work() by the completion of the target work item.  If,
      before task A starts executing, task B gets scheduled and invokes
      __cancel_work_timer() on the same work item, its try_to_grab_pending()
      will return -ENOENT as the work item is still being canceled by task A
      and flush_work() will also immediately return false as the work item
      is no longer executing.  This puts task B in a busy loop possibly
      preventing task A from executing and clearing the canceling state on
      the work item leading to a hang.
      
      task A			task B			worker
      
      						executing work
      __cancel_work_timer()
        try_to_grab_pending()
        set work CANCELING
        flush_work()
          block for work completion
      						completion, wakes up A
      			__cancel_work_timer()
      			while (forever) {
      			  try_to_grab_pending()
      			    -ENOENT as work is being canceled
      			  flush_work()
      			    false as work is no longer executing
      			}
      
      This patch removes the possible hang by updating __cancel_work_timer()
      to explicitly wait for clearing of CANCELING rather than invoking
      flush_work() after try_to_grab_pending() fails with -ENOENT.
      
      Link: http://lkml.kernel.org/g/20150206171156.GA8942@axis.com
      
      v3: bit_waitqueue() can't be used for work items defined in vmalloc
          area.  Switched to custom wake function which matches the target
          work item and exclusive wait and wakeup.
      
      v2: v1 used wake_up() on bit_waitqueue() which leads to NULL deref if
          the target bit waitqueue has wait_bit_queue's on it.  Use
          DEFINE_WAIT_BIT() and __wake_up_bit() instead.  Reported by Tomeu
          Vizoso.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
      Tested-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Tested-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1264f1e3
    • Jason Low's avatar
      cpuset: Fix cpuset sched_relax_domain_level · 6efeedf2
      Jason Low authored
      commit 283cb41f upstream.
      
      The cpuset.sched_relax_domain_level can control how far we do
      immediate load balancing on a system. However, it was found on recent
      kernels that echo'ing a value into cpuset.sched_relax_domain_level
      did not reduce any immediate load balancing.
      
      The reason this occurred was because the update_domain_attr_tree() traversal
      did not update for the "top_cpuset". This resulted in nothing being changed
      when modifying the sched_relax_domain_level parameter.
      
      This patch is able to address that problem by having update_domain_attr_tree()
      allow updates for the root in the cpuset traversal.
      
      Fixes: fc560a26 ("cpuset: replace cpuset->stack_list with cpuset_for_each_descendant_pre()")
      Signed-off-by: default avatarJason Low <jason.low2@hp.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Tested-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6efeedf2
    • Maxime Ripard's avatar
      mtd: nand: pxa3xx: Fix PIO FIFO draining · 41ba1af9
      Maxime Ripard authored
      commit 8dad0386 upstream.
      
      The NDDB register holds the data that are needed by the read and write
      commands.
      
      However, during a read PIO access, the datasheet specifies that after each 32
      bytes read in that register, when BCH is enabled, we have to make sure that the
      RDDREQ bit is set in the NDSR register.
      
      This fixes an issue that was seen on the Armada 385, and presumably other mvebu
      SoCs, when a read on a newly erased page would end up in the driver reporting a
      timeout from the NAND.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      41ba1af9
    • Torsten Fleischer's avatar
      spi: atmel: Fix interrupt setup for PDC transfers · 293a6372
      Torsten Fleischer authored
      commit 76e1d14b upstream.
      
      Additionally to the current DMA transfer the PDC allows to set up a next DMA
      transfer. This is useful for larger SPI transfers.
      
      The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
      when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
      next DMA transfer.
      Thus a subsequent SPI transfer could be started although there is currently a
      transfer in progress. This can cause invalid accesses to the SPI slave devices
      and to SPI transfer errors.
      
      This issue has been observed on a hardware with a M25P128 SPI NOR flash.
      
      So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
      no more DMA transfer in progress (RCR = RNCR = 0).
      Signed-off-by: default avatarTorsten Fleischer <torfl6749@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      293a6372
    • Andy Shevchenko's avatar
      spi: dw: revisit FIFO size detection again · e44ea338
      Andy Shevchenko authored
      commit 9d239d35 upstream.
      
      The commit d297933c (spi: dw: Fix detecting FIFO depth) tries to fix the
      logic of the FIFO detection based on the description on the comments. However,
      there is a slight difference between numbers in TX Level and TX FIFO size.
      
      So, by specification the FIFO size would be in a range 2-256 bytes. From TX
      Level prospective it means we can set threshold in the range 0-(FIFO size - 1)
      bytes. Hence there are currently two issues:
        a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
           either 0 or 1 byte;
        b) FIFO size is incorrectly decreased by 1 which already done by meaning of
           TX Level register.
      
      This patch fixes it eventually right.
      
      Fixes: d297933c (spi: dw: Fix detecting FIFO depth)
      Reviewed-by: default avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e44ea338
    • Sasha Levin's avatar
      PCI: Don't read past the end of sysfs "driver_override" buffer · d81b1275
      Sasha Levin authored
      commit 4efe874a upstream.
      
      When printing the driver_override parameter when it is 4095 and 4094 bytes
      long, the printing code would access invalid memory because we need count+1
      bytes for printing.
      
      Fixes: 782a985d ("PCI: Introduce new device binding path using pci_dev.driver_override")
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      CC: Alexander Graf <agraf@suse.de>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d81b1275
  2. 20 Mar, 2015 4 commits
  3. 18 Mar, 2015 13 commits