1. 08 5月, 2018 8 次提交
  2. 02 5月, 2018 1 次提交
  3. 07 3月, 2018 1 次提交
    • A
      scsi: mpt3sas: clarify mmio pointer types · 6f9e09fd
      Arnd Bergmann 提交于
      The newly added code mixes up phys_addr_t/resource_size_t with dma_addr_t
      and void pointers, as seen from these compiler warning:
      
      drivers/scsi/mpt3sas/mpt3sas_base.c: In function '_base_get_chain_phys':
      drivers/scsi/mpt3sas/mpt3sas_base.c:235:21: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
        base_chain_phys  = (void *)ioc->chip_phys + MPI_FRAME_START_OFFSET +
                           ^
      drivers/scsi/mpt3sas/mpt3sas_base.c: In function '_clone_sg_entries':
      drivers/scsi/mpt3sas/mpt3sas_base.c:427:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
          sgel->Address = (dma_addr_t)dst_addr_phys;
                          ^
      drivers/scsi/mpt3sas/mpt3sas_base.c:438:7: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
             (dma_addr_t)buff_ptr_phys;
             ^
      drivers/scsi/mpt3sas/mpt3sas_base.c:444:10: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
                (dma_addr_t)buff_ptr_phys;
      
      Both dma_addr_t and phys_addr_t may be wider than a pointer, so we must
      avoid the conversion to pointer types. This also helps readability.
      
      A second problem is treating MMIO addresses from a 'struct resource'
      as addresses that can be used for DMA on that device. In almost all
      cases, those are the same, but on some of the more obscure architectures,
      PCI memory address 0 is mapped into the CPU address space at a nonzero
      offset. I don't have a good fix for that, so I'm adding a comment here,
      plus a WARN_ON() that triggers whenever the phys_addr_t number is
      outside of the low 32-bit address space and causes a straight overflow
      when assigned to the 32-bit sgel->Address.
      
      Fixes: 182ac784 ("scsi: mpt3sas: Introduce Base function for cloning.")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSreekanth Reddy <Sreekanth.Reddy@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      6f9e09fd
  4. 28 2月, 2018 6 次提交
  5. 22 2月, 2018 1 次提交
  6. 31 1月, 2018 1 次提交
  7. 17 1月, 2018 1 次提交
  8. 11 1月, 2018 7 次提交
  9. 05 12月, 2017 1 次提交
  10. 07 11月, 2017 1 次提交
    • A
      scsi: mpt3sas: fix dma_addr_t casts · d8335ae2
      Arnd Bergmann 提交于
      The newly added base_make_prp_nvme function triggers a build warning on
      some 32-bit configurations:
      
      drivers/scsi/mpt3sas/mpt3sas_base.c: In function 'base_make_prp_nvme':
      drivers/scsi/mpt3sas/mpt3sas_base.c:1664:13: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
        msg_phys = (dma_addr_t)mpt3sas_base_get_pcie_sgl_dma(ioc, smid);
      
      After taking a closer look, I found that the problem is that the new
      code mixes up pointers and dma_addr_t values unnecessarily.
      
      This changes it to use the correct types consistently, which lets us get
      rid of a lot of type casts in the process. I'm also renaming some
      variables to avoid confusion between physical and dma address spaces
      that are often distinct.
      
      Fixes: 016d5c35 ("scsi: mpt3sas: SGL to PRP Translation for I/Os to NVMe devices")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSathya Prakash Veerichetty <sathya.prakash@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      d8335ae2
  11. 04 11月, 2017 4 次提交
  12. 31 10月, 2017 1 次提交
    • K
      treewide: Fix function prototypes for module_param_call() · e4dca7b7
      Kees Cook 提交于
      Several function prototypes for the set/get functions defined by
      module_param_call() have a slightly wrong argument types. This fixes
      those in an effort to clean up the calls when running under type-enforced
      compiler instrumentation for CFI. This is the result of running the
      following semantic patch:
      
      @match_module_param_call_function@
      declarer name module_param_call;
      identifier _name, _set_func, _get_func;
      expression _arg, _mode;
      @@
      
       module_param_call(_name, _set_func, _get_func, _arg, _mode);
      
      @fix_set_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._set_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _set_func(
      -_val_type _val
      +const char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      @fix_get_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._get_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _get_func(
      -_val_type _val
      +char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      Two additional by-hand changes are included for places where the above
      Coccinelle script didn't notice them:
      
      	drivers/platform/x86/thinkpad_acpi.c
      	fs/lockd/svc.c
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      e4dca7b7
  13. 12 10月, 2017 2 次提交
  14. 25 8月, 2017 1 次提交
  15. 11 8月, 2017 1 次提交
  16. 08 8月, 2017 1 次提交
  17. 25 4月, 2017 1 次提交
  18. 24 2月, 2017 1 次提交