1. 24 Aug, 2013 3 commits
  2. 23 Aug, 2013 14 commits
  3. 22 Aug, 2013 18 commits
    • Rafael J. Wysocki's avatar
      Revert "ACPI / video: Always call acpi_video_init_brightness() on init" · 168cf0ec
      Rafael J. Wysocki authored
      Revert commit c04c697c (ACPI / video: Always call acpi_video_init_brightness()
      on init), because it breaks eDP backlight at 1920x1080 on Acer Aspire S3
      for Trevor Bortins.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=68355Reported-and-bisected-by: default avatarTrevor Bortins <enabfluw@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      168cf0ec
    • David S. Miller's avatar
      Merge branch 'sfc-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc · 2266c68f
      David S. Miller authored
      Merge in a fix for RX MAC address filter programming bug in the sfc
      driver.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2266c68f
    • Johannes Berg's avatar
      Revert "genetlink: fix family dump race" · 9d47b380
      Johannes Berg authored
      This reverts commit 58ad436f.
      
      It turns out that the change introduced a potential deadlock
      by causing a locking dependency with netlink's cb_mutex. I
      can't seem to find a way to resolve this without doing major
      changes to the locking, so revert this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d47b380
    • Linus Torvalds's avatar
      Merge branch 'linux-next' of git://cavan.codon.org.uk/platform-drivers-x86 · 6a7492a4
      Linus Torvalds authored
      Pull x86 platform driver fixes from Matthew Garrett:
       "Three trivial fixes - the first reverts a patch that's broken some
        other devices (again - I'm trying to figure out a clean way to
        implement this), the other two fix minor issues in the sony-laptop
        driver"
      
      * 'linux-next' of git://cavan.codon.org.uk/platform-drivers-x86:
        Revert "hp-wmi: Enable hotkeys on some systems"
        sony-laptop: Fix reporting of gfx_switch_status
        sony-laptop: return a negative error code in sonypi_compat_init()
      6a7492a4
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 1f8b7665
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "A handful of fixes for 3.11 are still trickling in.  These are:
         - A couple of fixes for older OMAP platforms
         - Another few fixes for at91 (lateish due to European summer
           vacations)
         - A late-found problem with USB on Tegra, fix is to keep VBUS
           regulator on at all times
         - One fix for Exynos 5440 dealing with CPU detection
         - One MAINTAINERS update"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: tegra: always enable USB VBUS regulators
        ARM: davinci: nand: specify ecc strength
        ARM: OMAP: rx51: change musb mode to OTG
        ARM: OMAP2: fix musb usage for n8x0
        MAINTAINERS: Update email address for Benoit Cousson
        ARM: at91/DT: fix at91sam9n12ek memory node
        ARM: at91: add missing uart clocks DT entries
        ARM: SAMSUNG: fix to support for missing cpu specific map_io
        ARM: at91/DT: at91sam9x5ek: fix USB host property to enable port C
      1f8b7665
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-3.11' of git://sources.calxeda.com/kernel/linux · 8351fcfe
      Linus Torvalds authored
      Pull device tree fix from Rob Herring:
       "For DT unflattening, add missing memory initialization.
      
        This is needed for arches like PPC that use memblock_alloc.  This
        appears to have been an issue for some time, but is a somewhat limited
        usecase of OF_DYNAMIC"
      
      * tag 'devicetree-fixes-for-3.11' of git://sources.calxeda.com/kernel/linux:
        of: fdt: fix memory initialization for expanded DT
      8351fcfe
    • Linus Torvalds's avatar
      Merge tag 'dm-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · ee7075d4
      Linus Torvalds authored
      Pull device mapper fix from Mike Snitzer:
       "A patch to fix dm-cache-policy-mq's remove_mapping() conflict with
        sparc32"
      
      * tag 'dm-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm cache: avoid conflicting remove_mapping() in mq policy
      ee7075d4
    • Radu Caragea's avatar
      x86 get_unmapped_area: Access mmap_legacy_base through mm_struct member · 41aacc1e
      Radu Caragea authored
      This is the updated version of df54d6fa ("x86 get_unmapped_area():
      use proper mmap base for bottom-up direction") that only randomizes the
      mmap base address once.
      Signed-off-by: default avatarRadu Caragea <sinaelgl@gmail.com>
      Reported-and-tested-by: default avatarJeff Shorey <shoreyjeff@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Adrian Sendroiu <molecula2788@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      41aacc1e
    • Linus Torvalds's avatar
      Revert "x86 get_unmapped_area(): use proper mmap base for bottom-up direction" · 5ea80f76
      Linus Torvalds authored
      This reverts commit df54d6fa.
      
      The commit isn't necessarily wrong, but because it recalculates the
      random mmap_base every time, it seems to confuse user memory allocators
      that expect contiguous mmap allocations even when the mmap address isn't
      specified.
      
      In particular, the MATLAB Java runtime seems to be unhappy. See
      
        https://bugzilla.kernel.org/show_bug.cgi?id=60774
      
      So we'll want to apply the random offset only once, and Radu has a patch
      for that.  Revert this older commit in order to apply the other one.
      Reported-by: default avatarJeff Shorey <shoreyjeff@gmail.com>
      Cc: Radu Caragea <sinaelgl@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5ea80f76
    • Martin Peschke's avatar
      [SCSI] zfcp: remove access control tables interface (keep sysfs files) · b5dc3c48
      Martin Peschke authored
      By popular demand, this patch brings back a couple of sysfs attributes
      removed by commit 663e0890
      "[SCSI] zfcp: remove access control tables interface".
      The content has been irrelevant for years, but the files must be
      there forever for whatever user space tools that may rely on them.
      
      Since these files always return a constant value, a new stripped
      down show-macro was required. Otherwise build warnings would have
      been introduced.
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      b5dc3c48
    • Martin Peschke's avatar
      [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops · 924dd584
      Martin Peschke authored
      BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
      in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
      CPU: 1 Not tainted 3.9.3+ #69
      Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
      <snip>
      Call Trace:
      ([<00000000001165de>] show_trace+0x106/0x154)
       [<00000000001166a0>] show_stack+0x74/0xf4
       [<00000000006ff646>] dump_stack+0xc6/0xd4
       [<000000000017f3a0>] __might_sleep+0x128/0x148
       [<000000000015ece8>] flush_work+0x54/0x1f8
       [<00000000001630de>] __cancel_work_timer+0xc6/0x128
       [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
       [<0000000000161816>] execute_in_process_context+0x96/0xa8
       [<00000000004d33d8>] device_release+0x60/0xc0
       [<000000000048af48>] kobject_release+0xa8/0x1c4
       [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
       [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
       [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
       [<000000000016b75a>] kthread+0xf2/0xfc
       [<000000000070c9de>] kernel_thread_starter+0x6/0xc
       [<000000000070c9d8>] kernel_thread_starter+0x0/0xc
      
      Apparently, the ref_count for some scsi_device drops down to zero,
      triggering device removal through execute_in_process_context(), while
      the lldd error recovery thread iterates through a scsi device list.
      Unfortunately, execute_in_process_context() decides to immediately
      execute that device removal function, instead of scheduling asynchronous
      execution, since it detects process context and thinks it is safe to do
      so. But almost all calls to shost_for_each_device() in our lldd are
      inside spin_lock_irq, even in thread context. Obviously, schedule()
      inside spin_lock_irq sections is a bad idea.
      
      Change the lldd to use the proper iterator function,
      __shost_for_each_device(), in combination with required locking.
      
      Occurences that need to be changed include all calls in zfcp_erp.c,
      since those might be executed in zfcp error recovery thread context
      with a lock held.
      
      Other occurences of shost_for_each_device() in zfcp_fsf.c do not
      need to be changed (no process context, no surrounding locking).
      
      The problem was introduced in Linux 2.6.37 by commit
      b62a8d9b
      "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
      Reported-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.37+
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      924dd584
    • Martin Peschke's avatar
      [SCSI] zfcp: fix lock imbalance by reworking request queue locking · d79ff142
      Martin Peschke authored
      This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
      straight-forward descendant of wait_event_interruptible_timeout() and
      wait_event_interruptible_lock_irq().
      
      The zfcp driver used to call wait_event_interruptible_timeout()
      in combination with some intricate and error-prone locking. Using
      wait_event_interruptible_lock_irq_timeout() as a replacement
      nicely cleans up that locking.
      
      This rework removes a situation that resulted in a locking imbalance
      in zfcp_qdio_sbal_get():
      
      BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
          last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]
      
      It was introduced by commit c2af7545
      "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
      code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
      without a required lock being held. The problem occured when a
      special, non-SCSI I/O request was being submitted in process context,
      when the adapter's queues had been torn down. In this case the bug
      surfaced when the Fibre Channel port connection for a well-known address
      was closed during a concurrent adapter shut-down procedure, which is a
      rare constellation.
      
      This patch also fixes these warnings from the sparse tool (make C=1):
      
      drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
       'zfcp_qdio_sbal_check' - wrong count at exit
      drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
       'zfcp_qdio_sbal_get' - unexpected unlock
      
      Last but not least, we get rid of that crappy lock-unlock-lock
      sequence at the beginning of the critical section.
      
      It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.
      Reported-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reported-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.35+
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      d79ff142
    • Stephen Warren's avatar
      ARM: tegra: always enable USB VBUS regulators · 30ca2226
      Stephen Warren authored
      This fixes a regression exposed during the merge window by commit
      9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
      USB VBUS doesn't get turned on, so USB devices are not detected. This
      affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
      which the SSD is connected) and the external port(s) on Seaboard/
      Springbank and Whistler.
      
      The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:
      
      1) Via the legacy DT binding for the USB controller; it can directly
         acquire a VBUS GPIO and activate it.
      
      2) Via a regulator for VBUS, which is referenced by the new DT binding
         for the USB controller.
      
      Those two methods both use the same GPIO, and hence whichever of the
      USB controller and regulator gets probed first ends up owning the GPIO.
      In practice, the USB driver only supports path (1) above, since the
      patches to support the new USB binding are not present until v3.12:-(
      
      In practice, the regulator ends up being probed first and owning the
      GPIO. Since nothing enables the regulator (the USB driver code is not
      yet present), the regulator ends up being turned off. This originally
      caused no problem, because the polarity in the regulator definition was
      incorrect, so attempting to turn off the regulator actually turned it
      on, and everything worked:-(
      
      However, when testing the new USB driver code in v3.12, I noticed the
      incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
      regulator GPIO polarity in DT". In the context of v3.11, this patch then
      caused the USB VBUS to actually turn off, which broke USB ports with VBUS
      control. I got this patch included in v3.11-rc1 since it fixed a bug in
      device tree (incorrect polarity specification), and hence was suitable to
      be included early in the rc series. I evidently did not test the patch at
      all, or correctly, in the context of v3.11, and hence did not notice the
      issue that I have explained above:-(
      
      Fix this by making the USB VBUS regulators always enabled. This way, if
      the regulator owns the GPIO, it will always be turned on, even if there
      is no USB driver code to request the regulator be turned on. Even
      ignoring this bug, this is a reasonable way to configure the HW anyway.
      
      If this patch is applied to v3.11, it will cause a couple pretty trivial
      conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
      the context right above the added lines changed in patches destined for
      v3.12.
      Reported-by: default avatarKyle McMartin <kmcmarti@redhat.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      30ca2226
    • Daniel Gimpelevich's avatar
      hso: Fix stack corruption on some architectures · e75dc677
      Daniel Gimpelevich authored
      As Sergei Shtylyov explained in the #mipslinux IRC channel:
      [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
      [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
      [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
      [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
      [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
      [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
      Signed-off-by: default avatarDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e75dc677
    • Daniel Gimpelevich's avatar
      hso: Earlier catch of error condition · 35e57e1b
      Daniel Gimpelevich authored
      There is no need to get an interface specification if we know it's the
      wrong one.
      Signed-off-by: default avatarDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35e57e1b
    • Wladislav Wiebe's avatar
      of: fdt: fix memory initialization for expanded DT · 9e401275
      Wladislav Wiebe authored
      Already existing property flags are filled wrong for properties created from
      initial FDT. This could cause problems if this DYNAMIC device-tree functions
      are used later, i.e. properties are attached/detached/replaced. Simply dumping
      flags from the running system show, that some initial static (not allocated via
      kzmalloc()) nodes are marked as dynamic.
      
      I putted some debug extensions to property_proc_show(..) :
      ..
      +       if (OF_IS_DYNAMIC(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
      +       if (OF_IS_DETACHED(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
      
      when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
      will see that those flags are filled wrong, basically in most cases it will dump
      a DYNAMIC or DETACHED status, which is in not true.
      (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
      make a test_bit(OF_DETACHED, &x->_flags)
      
      If nodes are dynamic kernel is allowed to kfree() them. But it will crash
      attempting to do so on the nodes from FDT -- they are not allocated via
      kzmalloc().
      Signed-off-by: default avatarWladislav Wiebe <wladislav.kw@gmail.com>
      Acked-by: default avatarAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      9e401275
    • Guillaume Clement's avatar
      gma500: Fix SDVO turning off randomly · 6f1e1204
      Guillaume Clement authored
      Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off.
      Signed-off-by: default avatarGuillaume Clement <gclement@baobob.org>
      Acked-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6f1e1204
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-next' of... · 317b07b5
      Dave Airlie authored
      Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
      
      regression fixes and null derefs and oops fixes.
      
      * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
        drm/nv04/disp: fix framebuffer pin refcounting
        drm/nouveau/mc: fix race condition between constructor and request_irq()
        drm/nouveau: fix reclocking on nv40
        drm/nouveau/ltcg: fix allocating memory as free
        drm/nouveau/ltcg: fix ltcg memory initialization after suspend
        drm/nouveau/fb: fix null derefs in nv49 and nv4e init
      317b07b5
  4. 21 Aug, 2013 5 commits