Skip to content
Snippets Groups Projects
  1. Sep 27, 2016
  2. Aug 12, 2016
  3. Jul 20, 2016
  4. Jul 13, 2016
    • Randy Dunlap's avatar
      scsi: ultrastor.c depends on ISA_DMA_API · 7e1ee441
      Randy Dunlap authored
      
      Fix build when CONFIG_ISA_DMA_API is not enabled. Fixes these build
      errors (on x86_64):
      
      ../drivers/scsi/ultrastor.c: In function 'ultrastor_14f_detect':
      ../drivers/scsi/ultrastor.c:519:5: error: implicit declaration of function 'request_dma' [-Werror=implicit-function-declaration]
           if (config.dma_channel && request_dma(config.dma_channel,"Ultrastor")) {
           ^
      ../drivers/scsi/ultrastor.c: In function 'ultrastor_release':
      ../drivers/scsi/ultrastor.c:658:3: error: implicit declaration of function 'free_dma' [-Werror=implicit-function-declaration]
         free_dma(shost->dma_channel);
         ^
      
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7e1ee441
  5. Apr 15, 2016
  6. Apr 11, 2016
    • Finn Thain's avatar
      g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400 · 9d376402
      Finn Thain authored
      
      This change brings a number of improvements: fewer macros, better test
      coverage, simpler code and sane Kconfig options. The downside is a small
      chance of incompatibility (which seems unavoidable).
      
      CONFIG_SCSI_GENERIC_NCR53C400 exists to enable or inhibit pseudo DMA
      transfers when the driver is used with 53C400-compatible cards. Thanks to
      Ondrej Zary's patches, PDMA now works which means it can be enabled
      unconditionally.
      
      Due to bad design, CONFIG_SCSI_GENERIC_NCR53C400 ties together unrelated
      functionality as it sets both PSEUDO_DMA and BIOSPARAM macros. This patch
      effectively enables PSEUDO_DMA and disables BIOSPARAM.
      
      The defconfigs and the Kconfig default leave CONFIG_SCSI_GENERIC_NCR53C400
      undefined. Red Hat 9 and CentOS 2.1 were the same. This leaves both
      PSEUDO_DMA and BIOSPARAM disabled. The effect of this patch should be
      better performance from enabling PSEUDO_DMA.
      
      On the other hand, Debian 4 and SLES 10 had CONFIG_SCSI_GENERIC_NCR53C400
      enabled, so both PSEUDO_DMA and BIOSPARAM were enabled. This patch might
      affect configurations like this by disabling BIOSPARAM. My best guess is
      that this could be a problem only in the vanishingly rare case that
      1) the CHS values stored in the boot device partition table are wrong and
      2) a 5380 card is in use (because PDMA on 53C400 used to be broken).
      
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Tested-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9d376402
    • Rasmus Villemoes's avatar
      scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k · e1f0bce3
      Rasmus Villemoes authored
      
      On 64 bit, struct error_info has 6 bytes of padding, which amounts to
      over 4k of wasted space in the additional[] array. We could easily get
      rid of that by instead using separate arrays for the codes and the
      pointers. However, we can do even better than that and save an
      additional 6 bytes per entry: In the table, just store the sizeof()
      the corresponding string literal. The cumulative sum of these is then
      the appropriate offset into additional_text, which is built from the
      concatenation (with '\0's inbetween) of the strings.
      
      $ scripts/bloat-o-meter /tmp/vmlinux vmlinux
      add/remove: 0/0 grow/shrink: 1/1 up/down: 24/-8488 (-8464)
      function                                     old     new   delta
      scsi_extd_sense_format                       136     160     +24
      additional                                 11312    2824   -8488
      
      The Kconfig help text used to say that CONFIG_SCSI_CONSTANTS=y costs
      around 75 KB, but that was a little exaggerated. The actual number was
      closer to 44K, and 36K with this patch.
      
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Tested-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      e1f0bce3
  7. Mar 05, 2016
  8. Jan 07, 2016
    • Finn Thain's avatar
      atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT · 9c3f0e2b
      Finn Thain authored
      
      The atari_NCR5380.c core driver now takes care of bus reset upon driver
      initialization if required (same as NCR5380.c). Move the Toshiba CD-ROM
      support into the core driver, enabled with a host flag, so that all
      NCR5380 drivers can make use of it.
      
      Drop the RESET_BOOT macros and the ATARI_SCSI_RESET_BOOT and
      ATARI_SCSI_TOSHIBA_DELAY Kconfig symbols, which are now redundant.
      
      Remove the atari_scsi_reset_boot(), mac_scsi_reset_boot() and
      sun3_scsi_reset_boot() routines. None of this duplicated code is needed
      now that all drivers can use NCR5380_maybe_reset_bus().
      
      This brings atari_scsi, mac_scsi and sun3_scsi into line with all of the
      other NCR5380 drivers.
      
      The bus reset may raise an interrupt. That would be new behaviour for
      atari_scsi only when CONFIG_ATARI_SCSI_RESET_BOOT=n. The ST DMA interrupt
      is not assigned to atari_scsi at this stage, so
      CONFIG_ATARI_SCSI_RESET_BOOT=y may well be problematic already.
      Regardless, do_reset() now raises and clears the interrupt within
      local_irq_save/restore which should avoid problems.
      
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Tested-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9c3f0e2b
  9. Dec 19, 2015
  10. Dec 11, 2015
  11. Nov 26, 2015
  12. Nov 20, 2015
    • Arnd Bergmann's avatar
      scsi: hpsa: select CONFIG_SCSI_SAS_ATTR · 653cfb85
      Arnd Bergmann authored
      
      The hpsa driver recently started using the sas transport class, but it
      does not ensure that the corresponding code is actually built, which
      may lead to a link error:
      
      drivers/built-in.o: In function `hpsa_free_sas_phy':
      (.text+0x1ce874): undefined reference to `sas_port_delete_phy'
      (.text+0x1ce87c): undefined reference to `sas_phy_free'
      drivers/built-in.o: In function `hpsa_alloc_sas_port':
      (.text+0x1ceb9c): undefined reference to `sas_port_alloc_num'
      (.text+0x1ceba8): undefined reference to `sas_port_add'
      drivers/built-in.o: In function `hpsa_init':
      (.init.text+0x8838): undefined reference to `sas_attach_transport'
      (.init.text+0x8868): undefined reference to `sas_release_transport
      
      This adds 'select SCSI_SAS_ATTR' in the Kconfig entry, just like we do
      for all other drivers using those functions.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: d04e62b9 ("hpsa: add in sas transport class")
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarDon Brace <don.brace@pmcs.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      653cfb85
    • Arnd Bergmann's avatar
      scsi: advansys needs ISA dma api for ISA support · 2b8bbdb9
      Arnd Bergmann authored
      
      The advansys drvier uses the request_dma function that is used on ISA
      machines for the internal DMA controller, which causes build errors
      on platforms that have ISA slots but do not provide the ISA DMA API:
      
      drivers/scsi/advansys.c: In function 'advansys_board_found':
      drivers/scsi/advansys.c:11300:10: error: implicit declaration of function 'request_dma' [-Werror=implicit-function-declaration]
      
      The problem now showed up in ARM randconfig builds after commit
      6571fb3f ("advansys: Update to version 3.5 and remove compilation
      warning") made it possible to build on platforms that have neither
      VIRT_TO_BUS nor ISA_DMA_API but that do have ISA.
      
      This adds the missing dependency.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2b8bbdb9
  13. Nov 12, 2015
    • Sreekanth Reddy's avatar
      mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs · c84b06a4
      Sreekanth Reddy authored
      
      Modified the mpt3sas driver to have a single driver module which
      supports both SAS 2.0 & SAS 3.0 HBA devices.
      
      * Added SAS 2.0 HBA device IDs to the mpt3sas_pci_table pci table.
      
      * Created two separate SCSI host templates for SAS2 and SAS3 HBAs so
        that, during the driver load time driver can use corresponding host
        template(based the pci device ID) while registering a scsi host
        adapter instance for that pci device.
      
      * Registered two IOCTL devices, mpt2ctl is for SAS2 HBAs & mpt3ctl for
        SAS3 HBAs. Also updated the code to make sure that mpt2ctl device
        processes only those ioctl cmds issued for the SAS2 HBAs and mpt3ctl
        device processes only those ioctl cmds issued for the SAS3 HBAs.
      
      * Added separate indexing for SAS2 and SAS3 HBAs.
      
      * Replaced compile time check 'MPT2SAS_SCSI' to run time check
        'hba_mpi_version_belonged' whereever needed.
      
      * Aliased this merged driver to mpt2sas using MODULE_ALIAS.
      
      * Moved global varaible 'driver_name' to per adapter instance variable.
      
      * Created two raid function template and used corresponding raid
        function templates based on the run time check
        'hba_mpi_version_belonged'.
      
      * Moved mpt2sas_warpdrive.c file from mpt2sas to mpt3sas folder and
        renamed it as mpt3sas_warpdrive.c.
      
      * Also renamed the functions in mpt3sas_warpdrive.c file to follow
        current driver function name convention.
      
      * Updated the Makefile to build mpt3sas_warpdrive.o file for these
        WarpDrive-specific functions.
      
      * Also in function mpt3sas_setup_direct_io(), used sector_div() API
        instead of division operator (which gives compilation errors on 32 bit
        machines).
      
      * Removed mpt2sas files, mpt2sas directory & mpt3sas_module.c file.
      
      * Added module parameter 'hbas_to_enumerate' which permits using this
        merged driver as a legacy mpt2sas driver or as a legacy mpt3sas
        driver.
      
        Here are the available options for this module parameter:
      
         0 - Merged driver which enumerates both SAS 2.0 & SAS 3.0 HBAs
         1 - Acts as legacy mpt2sas driver, which enumerates only SAS 2.0 HBAs
         2 - Acts as legacy mpt3sas driver, which enumerates only SAS 3.0 HBAs
      
      * Removed mpt2sas entries from SCSI's Kconfig and Makefile files.
      
      Signed-off-by: default avatarSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c84b06a4
  14. Sep 29, 2015
  15. Jul 31, 2015
  16. Jun 19, 2015
  17. May 26, 2015
  18. May 25, 2015
  19. Jan 09, 2015
  20. Dec 15, 2014
  21. Nov 25, 2014
  22. Nov 24, 2014
  23. Nov 20, 2014
  24. Oct 03, 2014
  25. Oct 01, 2014
  26. Sep 27, 2014
  27. Sep 23, 2014
    • Juergen Gross's avatar
      xen-scsifront: Add Xen PV SCSI frontend driver · 8beb8d4c
      Juergen Gross authored
      
      Introduces the Xen pvSCSI frontend. With pvSCSI it is possible for a
      Xen domU to issue SCSI commands to a SCSI LUN assigned to that
      domU. The SCSI commands are passed to the pvSCSI backend in a driver
      domain (usually Dom0) which is owner of the physical device. This
      allows e.g. to use SCSI tape drives in a Xen domU.
      
      The code is taken from the pvSCSI implementation in Xen done by
      Fujitsu based on Linux kernel 2.6.18.
      
      Changes from the original version are:
      - port to upstream kernel
      - put all code in just one source file
      - move module to appropriate location in kernel tree
      - adapt to Linux style guide
      - some minor code simplifications
      - replace constants with defines
      - remove not used defines
      - add support for larger SG lists by putting them in a granted page
      
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      8beb8d4c
  28. Sep 22, 2014
  29. Sep 16, 2014
    • Randy Dunlap's avatar
      scsi: use 'depends' instead of 'select' for SCSI_FC_ATTRS · 6a38792c
      Randy Dunlap authored
      
      There are other kconfig symbols which use SCSI_FC_ATTRS.
      In order to maintain sanity and prevent kconfig warnings, change
      all of these from using 'select' to using 'depends on' so that
      proper symbol dependencies will be honored and circular depends
      problems will be avoided.
      This fixes kconfig warnings and build errors:
      
      warning: (LIBFC && SCSI_IBMVFC && SCSI_QLA_FC && SCSI_LPFC && ZFCP && SCSI_BFA_FC && SCSI_CHELSIO_FCOE && FUSION_FC) selects SCSI_FC_ATTRS which has unmet direct dependencies (SCSI && NET)
      drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_event':
      drivers/scsi/scsi_transport_fc.c:543:7: error: 'scsi_nl_sock' undeclared (first use in this function)
      drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_vendor_event':
      drivers/scsi/scsi_transport_fc.c:611:7: error: 'scsi_nl_sock' undeclared (first use in this function)
      
      Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot]
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a38792c
Loading