[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114111109.GA18673@infradead.org>
Date: Mon, 14 Jan 2019 03:11:09 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Vinayak Holikatti <vinholikatti@...il.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org,
Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH] scsi: ufs: Consider device limitations for dma_mask
On Fri, Jan 11, 2019 at 02:54:02PM -0800, Bjorn Andersson wrote:
> */
> static int ufshcd_set_dma_mask(struct ufs_hba *hba)
> {
> - if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
> - if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
> - return 0;
> - }
> - return dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(32));
> + u64 dma_mask = dma_get_mask(hba->dev);
> +
> + if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT)
> + dma_mask &= DMA_BIT_MASK(64);
> + else
> + dma_mask &= DMA_BIT_MASK(32);
> +
> + return dma_set_mask_and_coherent(hba->dev, dma_mask);
NAK. ufshcd clearly is in charge of setting the dma mask, so reading
it back from someone else who might have set it is completely bogus.
You either need to introduce a quirk or a way to communicate the
different limit so that it can be set by the core.
Powered by blists - more mailing lists