1. 27 10月, 2015 1 次提交
  2. 16 10月, 2015 1 次提交
    • A
      ahci: qoriq: Fix a compiling warning · eb351031
      Arnd Bergmann 提交于
      kbuild test robot reports the warnings:
      drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
      >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
      >> uninitialized in this function [-Wuninitialized]
      drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
      >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
      >> uninitialized in this function [-Wuninitialized]
      drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
      
      This patch fixed it by introducing a local variable.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTang Yuantian <Yuantian.Tang@freescale.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      eb351031
  3. 15 10月, 2015 1 次提交
  4. 13 10月, 2015 1 次提交
  5. 05 10月, 2015 1 次提交
  6. 01 10月, 2015 1 次提交
    • M
      ata: ahci: find eSATA ports and flag them as removable · 8a3e33cf
      Manuel Lauss 提交于
      If the AHCI ports' HPCP or ESP bits are set, the port
      should be considered external (e.g. eSATA) and is marked
      as removable.  Userspace tools like udisks then treat it
      like an usb drive.
      
      With this patch applied, when I plug a drive into the esata port,
      KDE pops up a window asking what to do with the drives(s), just
      like it does for any random USB stick.
      
      Removability is indicated to the upper layers by way of the
      SCSI RMB bit, as I haven't found another way to signal
      userspace to treat a sata disk like any usb stick.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      8a3e33cf
  7. 25 9月, 2015 1 次提交
  8. 11 9月, 2015 1 次提交
  9. 09 9月, 2015 2 次提交
  10. 03 9月, 2015 1 次提交
    • A
      MIPS: Remove all the uses of custom gpio.h · 832f5dac
      Alban Bedel 提交于
      Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS
      machines, and each machine type provides its own gpio.h. However
      only a handful really implement the GPIO API, most just forward
      everythings to gpiolib.
      
      The Alchemy machine is notable as it provides a system to allow
      implementing the GPIO API at the board level. But it is not used by
      any board currently supported, so it can also be removed.
      
      For most machine types we can just remove the custom gpio.h, as well
      as the custom wrappers if some exists. Some of the code found in
      the wrappers must be moved to the respective GPIO driver.
      
      A few more fixes are need in some drivers as they rely on linux/gpio.h
      to provides some machine specific definitions, or used asm/gpio.h
      instead of linux/gpio.h for the gpio API.
      Signed-off-by: NAlban Bedel <albeu@free.fr>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Florian Fainelli <florian@openwrt.org>
      Cc: Manuel Lauss <manuel.lauss@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Daniel Walter <dwalter@google.com>
      Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: James Hartley <james.hartley@imgtec.com>
      Cc: Andrew Bresticker <abrestic@chromium.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Varka Bhadram <varkabhadram@gmail.com>
      Cc: Masanari Iida <standby24x7@gmail.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Michael Buesch <m@bues.ch>
      Cc: abdoulaye berthe <berthe.ab@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-ide@vger.kernel.org
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-input@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/10828/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      832f5dac
  11. 26 8月, 2015 1 次提交
  12. 25 8月, 2015 1 次提交
    • Z
      PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI · 91f15fb3
      Zhang Rui 提交于
      On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
      function 1 doesn't work if it is powered on before the SATA controller at
      function 0.  The result is that PATA doesn't work after resume, and we
      print messages like this:
      
        pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
        irq 17: nobody cared (try booting with the "irqpoll" option)
      
      Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
      Asynchronous threads for resume_noirq").  Prior to that, we powered on
      the functions in order, so this problem shouldn't happen.
      
      e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
      solved the problem for JMicron 361 and 363 devices.  With async suspend
      disabled, we always power on function 0 before function 1.
      
      Barto then reported the same problem with a JMicron 368 (see comment #57 in
      the bugzilla).
      
      Rather than extending the blacklist piecemeal, disable async suspend for
      all JMicron multi-function SATA/PATA/AHCI devices.
      
      This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
      the problem will occur even if pata_jmicron isn't loaded until after the
      suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
      power-on order even if the drivers aren't loaded.
      
      [bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: NBarto <mister.freeman@laposte.net>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      91f15fb3
  13. 23 8月, 2015 1 次提交
  14. 10 8月, 2015 1 次提交
  15. 07 8月, 2015 2 次提交
  16. 04 8月, 2015 2 次提交
    • T
      Revert "libata: Implement NCQ autosense" · 74a80d67
      Tejun Heo 提交于
      This reverts commit 42b966fb.
      
      As implemented, ACS-4 sense reporting for ATA devices bypasses error
      diagnosis and handling in libata degrading EH behavior significantly.
      Revert the related changes for now.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org #v4.1+
      74a80d67
    • T
      Revert "libata: Implement support for sense data reporting" · 84ded2f8
      Tejun Heo 提交于
      This reverts commit fe7173c2.
      
      As implemented, ACS-4 sense reporting for ATA devices bypasses error
      diagnosis and handling in libata degrading EH behavior significantly.
      Revert the related changes for now.
      
      ATA_ID_COMMAND_SET_3/4 constants are not reverted as they're used by
      later changes.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: stable@vger.kernel.org #v4.1+
      84ded2f8
  17. 03 8月, 2015 1 次提交
  18. 29 7月, 2015 1 次提交
  19. 18 7月, 2015 1 次提交
  20. 17 7月, 2015 1 次提交
  21. 15 7月, 2015 7 次提交
  22. 07 7月, 2015 1 次提交
  23. 19 6月, 2015 1 次提交
  24. 18 6月, 2015 2 次提交
  25. 17 6月, 2015 2 次提交
    • R
      ahci: Add support for Cavium's ThunderX host controller · b7ae128d
      Robert Richter 提交于
      This patch adds support for Cavium's ThunderX host controller. The
      controller resides on the SoC and is a AHCI compatible SATA controller
      with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
      There can exists multiple SATA controllers on the SoC.
      
      The controller depends on MSI-X support since the PCI ECAM controller
      on the SoC does not implement MSI nor lagacy intx interrupt support.
      Thus, during device initialization, if MSI fails MSI-X will be used to
      enable the device's interrupts.
      
      The controller uses non-standard BAR0 for its register range. The
      already existing device lookup (vendor and device id) that is already
      implemented for other host controllers is used to change the PCI BAR.
      Signed-off-by: NRobert Richter <rrichter@cavium.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      b7ae128d
    • R
      ahci: Add generic MSI-X support for single interrupts to SATA PCI driver · ee2aad42
      Robert Richter 提交于
      This patch adds generic MSI-X support for single interrupts to the
      SATA PCI driver. MSI-X support is needed for host controller that only
      have MSI-X support implemented, but no MSI or intx. This patch only
      adds support for single interrupts, multiple per-port MSI-X interrupts
      are not yet implemented.
      
      The new implementation still initializes MSIs first. Only if that
      fails, the code tries to enable MSI-X. If that fails too, setup is
      continued with intx interrupts.
      
      To not break other chips by this generic code change, there are the
      following precautions:
      
       * Interrupt ranges are not enabled at all.
      
       * Only single interrupt mode is enabled for msix cap devices. Thus,
         only one interrupt will be setup.
      
       * During the discussion with Tejun we agreed to change the init
         sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
         offers msi and init does not fail, the msix init code will not be
         executed. This is equivalent to current code.
      
      With this, the code only setups single mode msix as a last resort if
      msi fails. No interrupt range is enabled at all. Only one interrupt
      will be enabled.
      
      tj: comment edits.
      
      Changes of the patch series:
      
      v5:
       * updated patch subject that the patch only implements single IRQ
       * moved Cavium specific code to a separate patch
       * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
         instead of vendor/dev id
       * added more comments to the code
       * enable single msix support for all kind of devices (removing strict
         check)
       * rebased onto update libata/for-4.2 with patch 1, 2 applied
      
      v4:
       * removed implementation of ahci_init_intx()
       * improved patch descriptions
       * rebased onto libata/for-4.2
      
      v3:
       * store irq number in struct ahci_host_priv
       * change initialization order from msix-msi-intx to msi-msix-intx
       * improve comments in ahci_init_msix()
       * improve error message in ahci_init_msix()
       * do not enable MSI-X if MSI is actively disabled for the device
      
      v2:
       * determine irq vector from pci_dev->msi_list
      
      Based on a patch from Sunil Goutham <sgoutham@cavium.com>.
      Signed-off-by: NRobert Richter <rrichter@cavium.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      ee2aad42
  26. 10 6月, 2015 2 次提交
  27. 09 6月, 2015 1 次提交
  28. 08 6月, 2015 1 次提交