> On 8/19/2013 8:02 PM, James Bottomley wrote: >> On Mon, 2013-08-19 at 22:56 +0900, Akinobu Mita wrote: >>> The device-tree probed device for ARM doesn't have dev->dma_mask. >>> So dma_set_mask() for the device doesn't succeed. The popular trick >>> for this is - dev->dma_mask = &dev->coherent_dma_mask; >>> >>> Currently there is no dma_set_mask() call in ufs-pltfrm, but the >>> forthcoming fix needs proper DMA mask setting in ufs core driver. So >>> initializing dev->dma_mask as described above is required. >>> >>> Signed-off-by: Akinobu Mita <mita@xxxxxxxxxxxx> >>> Cc: Sujit Reddy Thumma <sthumma@xxxxxxxxxxxxxx> >>> Cc: Vinayak Holikatti <vinholikatti@xxxxxxxxx> >>> Cc: Santosh Y <santoshsy@xxxxxxxxx> >>> Cc: "James E.J. Bottomley" <JBottomley@xxxxxxxxxxxxx> >>> Cc: linux-scsi@xxxxxxxxxxxxxxx >>> --- >>> drivers/scsi/ufs/ufshcd-pltfrm.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c >>> b/drivers/scsi/ufs/ufshcd-pltfrm.c >>> index 94ba40c..c780840 100644 >>> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c >>> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c >>> @@ -122,6 +122,9 @@ static int ufshcd_pltfrm_probe(struct >>> platform_device *pdev) >>> goto out; >>> } >>> >>> +if (!dev->dma_mask) >>> +dev->dma_mask = &dev->coherent_dma_mask; >>> + >> >> If the DMA mask is NULL, it means there's buggy platform code somewhere; >> I'm not sure we should be hacking a fix in a SCSI driver. > > Yes, ideally DT core should do this, there are patches lying around but > are not converged. Adding devicetree@xxxxxxxxxxxxxxx to see if someone > has better suggestions. > > Recent additions to kernel with similar hacks - > https://patchwork.kernel.org/patch/2537021/ The discussion in that thread is useful. Also, I found that Russell King proposed replacing the boilerplate by using dma_coerce_mask_and_coherent() in his patch set "Preview of DMA mask changes". https://patchwork.kernel.org/patch/2837359/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
