1. 31 8月, 2013 27 次提交
  2. 30 8月, 2013 2 次提交
  3. 24 8月, 2013 4 次提交
    • A
      usb: phy: fix build breakage · 52d5b9ab
      Anatolij Gustschin 提交于
      Commit 94ae9843 (usb: phy: rename all phy drivers to phy-$name-usb.c)
      renamed drivers/usb/phy/otg_fsm.h to drivers/usb/phy/phy-fsm-usb.h
      but changed drivers/usb/phy/phy-fsm-usb.c to include not existing
      "phy-otg-fsm.h" instead of new "phy-fsm-usb.h". This breaks building:
        ...
        drivers/usb/phy/phy-fsm-usb.c:32:25: fatal error: phy-otg-fsm.h: No such file or directory
        compilation terminated.
        make[3]: *** [drivers/usb/phy/phy-fsm-usb.o] Error 1
      
      This commit also missed to modify drivers/usb/phy/phy-fsl-usb.h
      to include new "phy-fsm-usb.h" instead of "otg_fsm.h" resulting
      in another build breakage:
        ...
        In file included from drivers/usb/phy/phy-fsl-usb.c:46:0:
        drivers/usb/phy/phy-fsl-usb.h:18:21: fatal error: otg_fsm.h: No such file or directory
        compilation terminated.
        make[3]: *** [drivers/usb/phy/phy-fsl-usb.o] Error 1
      
      Fix both issues.
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Cc: stable <stable@vger.kernel.org> # 3.10+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52d5b9ab
    • A
      USB: OHCI: add missing PCI PM callbacks to ohci-pci.c · 9a11899c
      Alan Stern 提交于
      Commit c1117afb (USB: OHCI: make ohci-pci a separate driver)
      neglected to preserve the entries for the pci_suspend and pci_resume
      driver callbacks.  As a result, OHCI controllers don't work properly
      during suspend and after hibernation.
      
      This patch adds the missing callbacks to the driver.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NSteve Cotton <steve@s.cotton.clara.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a11899c
    • I
      staging: comedi: bug-fix NULL pointer dereference on failed attach · 3955dfa8
      Ian Abbott 提交于
      Commit dcd7b8bd ("staging: comedi: put
      module _after_ detach" by myself) reversed a couple of calls in
      `comedi_device_attach()` when recovering from an error returned by the
      low-level driver's 'attach' handler.  Unfortunately, that introduced a
      NULL pointer dereference bug as `dev->driver` is NULL after the call to
      `comedi_device_detach()`.   We still have a pointer to the low-level
      comedi driver structure in the `driv` variable, so use that instead.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: <stable@vger.kernel.org> # 3.10+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3955dfa8
    • D
      drivers/platform/olpc/olpc-ec.c: initialise earlier · 93dbc1b3
      Daniel Drake 提交于
      Being a low-level component, various drivers (e.g.  olpc-battery) assume
      that it is ok to communicate with the OLPC Embedded Controller during
      probe.  Therefore the OLPC EC driver must be initialised before other
      drivers try to use it.  This was the case until it was recently moved
      out of arch/x86 and restructured around commits ac250415 ("Platform:
      OLPC: turn EC driver into a platform_driver") and 85f90cf6 ("x86:
      OLPC: switch over to using new EC driver on x86").
      
      Use arch_initcall so that olpc-ec is readied earlier, matching the
      previous behaviour.
      
      Fixes a regression introduced in Linux-3.6 where various drivers such as
      olpc-battery and olpc-xo1-sci failed to load due to an inability to
      communicate with the EC.  The user-visible effect was a lack of battery
      monitoring, missing ebook/lid switch input devices, etc.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Cc: Andres Salomon <dilinger@queued.net>
      Cc: Paul Fox <pgf@laptop.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      93dbc1b3
  4. 23 8月, 2013 4 次提交
    • S
      be2net: fix disabling TX in be_close() · 6e1f9975
      Sathya Perla 提交于
      commit fba87559 ("disable TX in be_close()") disabled TX in be_close()
      to protect be_xmit() from touching freed up queues in the AER recovery
      flow.  But, TX must be disabled *before* cleaning up TX completions in
      the close() path, not after. This allows be_tx_compl_clean() to free up
      all TX-req skbs that were notified to the HW.
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e1f9975
    • R
      Revert "ACPI / video: Always call acpi_video_init_brightness() on init" · 168cf0ec
      Rafael J. Wysocki 提交于
      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: NTrevor Bortins <enabfluw@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      168cf0ec
    • M
      [SCSI] zfcp: remove access control tables interface (keep sysfs files) · b5dc3c48
      Martin Peschke 提交于
      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: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b5dc3c48
    • M
      [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops · 924dd584
      Martin Peschke 提交于
      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: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.37+
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      924dd584
  5. 22 8月, 2013 3 次提交
    • M
      [SCSI] zfcp: fix lock imbalance by reworking request queue locking · d79ff142
      Martin Peschke 提交于
      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: NMikulas Patocka <mpatocka@redhat.com>
      Reported-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.35+
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      d79ff142
    • D
      hso: Fix stack corruption on some architectures · e75dc677
      Daniel Gimpelevich 提交于
      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: NDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e75dc677
    • D
      hso: Earlier catch of error condition · 35e57e1b
      Daniel Gimpelevich 提交于
      There is no need to get an interface specification if we know it's the
      wrong one.
      Signed-off-by: NDaniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35e57e1b