Re: [PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

Hi, On 11/30/20 8:30 PM, Tom Yan wrote: > Hmm, I wonder if I/we wrongly assumed that the dma_dev used for the > hw_max_sectors clamping in __scsi_init_queue() is wrong. > > So instead of adding a fallback else-clause here or using "sysdev" as > dma_dev like in the current upstream code, maybe we

Re: [PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

Hmm, I wonder if I/we wrongly assumed that the dma_dev used for the hw_max_sectors clamping in __scsi_init_queue() is wrong. So instead of adding a fallback else-clause here or using "sysdev" as dma_dev like in the current upstream code, maybe we should actually do a three-way min: the "changed" h

Re: [PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

Hi, On 11/28/20 4:48 PM, Tom Yan wrote: > Apparently the former (with the chosen dma_dev) may cause problem in certain > case (e.g. where thunderbolt dock and intel iommu are involved). The error > observed was: > > XHCI swiotlb buffer is full / DMAR: Device bounce map failed > > For now we reta

[PATCH 1/2] uas: revert from scsi_add_host_with_dma() to scsi_add_host()

Apparently the former (with the chosen dma_dev) may cause problem in certain case (e.g. where thunderbolt dock and intel iommu are involved). The error observed was: XHCI swiotlb buffer is full / DMAR: Device bounce map failed For now we retain the clamp for hw_max_sectors against the dma_max_map