1. 30 11月, 2016 1 次提交
  2. 15 11月, 2016 2 次提交
  3. 10 5月, 2016 2 次提交
  4. 18 4月, 2016 1 次提交
  5. 10 11月, 2015 2 次提交
  6. 01 6月, 2015 1 次提交
  7. 04 12月, 2014 1 次提交
  8. 27 11月, 2014 1 次提交
    • C
      libsas: remove task_collector mode · 79855d17
      Christoph Hellwig 提交于
      The task_collector mode (or "latency_injector", (C) Dan Willians) is an
      optional I/O path in libsas that queues up scsi commands instead of
      directly sending it to the hardware.  It generall increases latencies
      to in the optiomal case slightly reduce mmio traffic to the hardware.
      
      Only the obsolete aic94xx driver and the mvsas driver allowed to use
      it without recompiling the kernel, and most drivers didn't support it
      at all.
      
      Remove the giant blob of code to allow better optimizations for scsi-mq
      in the future.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      79855d17
  9. 24 11月, 2014 1 次提交
  10. 12 11月, 2014 1 次提交
  11. 06 11月, 2014 1 次提交
  12. 29 10月, 2014 1 次提交
  13. 13 8月, 2014 1 次提交
  14. 29 7月, 2014 1 次提交
  15. 18 4月, 2014 1 次提交
  16. 16 3月, 2014 2 次提交
  17. 10 3月, 2014 2 次提交
    • L
      [SCSI] isci: correct erroneous for_each_isci_host macro · c59053a2
      Lukasz Dorau 提交于
      In the first place, the loop 'for' in the macro 'for_each_isci_host'
      (drivers/scsi/isci/host.h:314) is incorrect, because it accesses
      the 3rd element of 2 element array. After the 2nd iteration it executes
      the instruction:
              ihost = to_pci_info(pdev)->hosts[2]
      (while the size of the 'hosts' array equals 2) and reads an
      out of range element.
      
      In the second place, this loop is incorrectly optimized by GCC v4.8
      (see http://marc.info/?l=linux-kernel&m=138998871911336&w=2).
      As a result, on platforms with two SCU controllers,
      the loop is executed more times than it can be (for i=0,1 and 2).
      It causes kernel panic during entering the S3 state
      and the following oops after 'rmmod isci':
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff8131360b>] __list_add+0x1b/0xc0
      Oops: 0000 [#1] SMP
      RIP: 0010:[<ffffffff8131360b>]  [<ffffffff8131360b>] __list_add+0x1b/0xc0
      Call Trace:
        [<ffffffff81661b84>] __mutex_lock_slowpath+0x114/0x1b0
        [<ffffffff81661c3f>] mutex_lock+0x1f/0x30
        [<ffffffffa03e97cb>] sas_disable_events+0x1b/0x50 [libsas]
        [<ffffffffa03e9818>] sas_unregister_ha+0x18/0x60 [libsas]
        [<ffffffffa040316e>] isci_unregister+0x1e/0x40 [isci]
        [<ffffffffa0403efd>] isci_pci_remove+0x5d/0x100 [isci]
        [<ffffffff813391cb>] pci_device_remove+0x3b/0xb0
        [<ffffffff813fbf7f>] __device_release_driver+0x7f/0xf0
        [<ffffffff813fc8f8>] driver_detach+0xa8/0xb0
        [<ffffffff813fbb8b>] bus_remove_driver+0x9b/0x120
        [<ffffffff813fcf2c>] driver_unregister+0x2c/0x50
        [<ffffffff813381f3>] pci_unregister_driver+0x23/0x80
        [<ffffffffa04152f8>] isci_exit+0x10/0x1e [isci]
        [<ffffffff810d199b>] SyS_delete_module+0x16b/0x2d0
        [<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0
        [<ffffffff8166ce29>] system_call_fastpath+0x16/0x1b
      
      The loop has been corrected.
      This patch fixes kernel panic during entering the S3 state
      and the above oops.
      Signed-off-by: NLukasz Dorau <lukasz.dorau@intel.com>
      Reviewed-by: NMaciej Patelczyk <maciej.patelczyk@intel.com>
      Tested-by: NLukasz Dorau <lukasz.dorau@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      c59053a2
    • D
      [SCSI] isci: fix reset timeout handling · ddfadd77
      Dan Williams 提交于
      Remove an erroneous BUG_ON() in the case of a hard reset timeout.  The
      reset timeout handler puts the port into the "awaiting link-up" state.
      The timeout causes the device to be disconnected and we need to be in
      the awaiting link-up state to re-connect the port.  The BUG_ON() made
      the incorrect assumption that resets never timeout and we always
      complete the reset in the "resetting" state.
      
      Testing this patch also uncovered that libata continues to attempt to
      reset the port long after the driver has torn down the context.  Once
      the driver has committed to abandoning the link it must indicate to
      libata that recovery ends by returning -ENODEV from
      ->lldd_I_T_nexus_reset().
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NLukasz Dorau <lukasz.dorau@intel.com>
      Reported-by: NDavid Milburn <dmilburn@redhat.com>
      Reported-by: NXun Ni <xun.ni@intel.com>
      Tested-by: NXun Ni <xun.ni@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      ddfadd77
  18. 26 8月, 2013 1 次提交
  19. 25 7月, 2013 1 次提交
  20. 23 7月, 2013 1 次提交
  21. 05 6月, 2013 1 次提交
    • J
      [SCSI] libsas: implement > 16 byte CDB support · e73823f7
      James Bottomley 提交于
      Remove the arbitrary expectation in libsas that all SCSI commands are 16 bytes
      or less.  Instead do all copies via cmd->cmd_len (and use a pointer to this in
      the libsas task instead of a copy).  Note that this still doesn't enable > 16
      byte CDB support in the underlying drivers because their internal format has
      to be fixed and the wire format of > 16 byte CDBs according to the SAS spec is
      different.  the libsas drivers (isci, aic94xx, mvsas and pm8xxx are all
      updated for this change.
      
      Cc: Lukasz Dorau <lukasz.dorau@intel.com>
      Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Jack Wang <xjtuwjp@gmail.com>
      Cc: Lindar Liu <lindar_liu@usish.com>
      Cc: Xiangliang Yu <yuxiangl@marvell.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e73823f7
  22. 10 5月, 2013 1 次提交
    • J
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley 提交于
      These enums have been separate since the dawn of SAS, mainly because the
      latter is a procotol only enum and the former includes additional state
      for libsas.  The dichotomy causes endless confusion about which one you
      should use where and leads to pointless warnings like this:
      
      drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
      drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]
      
      Fix by eliminating one of them.  The one kept is effectively the sas.h
      one, but call it sas_device_type and make sure the enums are all
      properly namespaced with the SAS_ prefix.
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  23. 12 4月, 2013 1 次提交
  24. 31 1月, 2013 1 次提交
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  25. 04 1月, 2013 1 次提交
    • G
      Drivers: scsi: remove __dev* attributes. · 6f039790
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Adam Radford <linuxraid@lsi.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f039790
  26. 13 11月, 2012 1 次提交
  27. 24 9月, 2012 2 次提交
  28. 02 9月, 2012 1 次提交
  29. 01 9月, 2012 1 次提交
  30. 24 8月, 2012 1 次提交
  31. 20 7月, 2012 1 次提交
  32. 04 7月, 2012 3 次提交