Broadcom folks: Please review! > 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.
-- Martin K. Petersen Oracle Linux Engineering
