All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <mani@kernel.org>
To: Bjorn Andersson <quic_bjorande@quicinc.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>,
	Bart Van Assche <bvanassche@acm.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Asutosh Das <quic_asutoshd@quicinc.com>,
	Bean Huo <beanhuo@micron.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Jinyoung Choi <j-young.choi@samsung.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] scsi: ufs: core: Limit DMA alignment check
Date: Wed, 1 Feb 2023 15:57:48 +0530	[thread overview]
Message-ID: <20230201102748.GA62808@thinkpad> (raw)
In-Reply-To: <20230201034917.1902330-1-quic_bjorande@quicinc.com>

On Tue, Jan 31, 2023 at 07:49:17PM -0800, Bjorn Andersson wrote:
> The three DMA memory regions allocated for the host memory space is
> documented to require alignment of 128, 1024 and 1024 respectively, but
> the returned address is checked for PAGE_SIZE alignment.
> 
> In the case these allocations are serviced by e.g. the Arm SMMU, the
> size and alignment will be determined by its supported page sizes. In
> most cases SZ_4K and a few larger sizes are available.
> 
> In the typical configuration this does not cause problems, but in the
> event that the system PAGE_SIZE is increased beyond 4k, it's no longer
> reasonable to expect that the allocation will be PAGE_SIZE aligned.
> 
> Limit the DMA alignment check to the actual alignment requirements
> written in the comments in the code, to avoid the UFS core refusing to
> initialize with such configuration.

Isn't dma_alloc_coherent() supposed to return PAGE_SIZE aligned dma and cpu
addresses? I suppose that could be reason for checking against PAGE_SIZE.

> 
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>

But it doesn't hurt to check for the actual alignment.

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

Thanks,
Mani

> ---
>  drivers/ufs/core/ufshcd.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ec732e4bbbf4..d7f3f1ba9d12 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -3724,12 +3724,9 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
>  
>  	/*
>  	 * UFSHCI requires UTP command descriptor to be 128 byte aligned.
> -	 * make sure hba->ucdl_dma_addr is aligned to PAGE_SIZE
> -	 * if hba->ucdl_dma_addr is aligned to PAGE_SIZE, then it will
> -	 * be aligned to 128 bytes as well
>  	 */
>  	if (!hba->ucdl_base_addr ||
> -	    WARN_ON(hba->ucdl_dma_addr & (PAGE_SIZE - 1))) {
> +	    WARN_ON(hba->ucdl_dma_addr & (128 - 1))) {
>  		dev_err(hba->dev,
>  			"Command Descriptor Memory allocation failed\n");
>  		goto out;
> @@ -3745,7 +3742,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
>  						   &hba->utrdl_dma_addr,
>  						   GFP_KERNEL);
>  	if (!hba->utrdl_base_addr ||
> -	    WARN_ON(hba->utrdl_dma_addr & (PAGE_SIZE - 1))) {
> +	    WARN_ON(hba->utrdl_dma_addr & (1024 - 1))) {
>  		dev_err(hba->dev,
>  			"Transfer Descriptor Memory allocation failed\n");
>  		goto out;
> @@ -3769,7 +3766,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
>  						    &hba->utmrdl_dma_addr,
>  						    GFP_KERNEL);
>  	if (!hba->utmrdl_base_addr ||
> -	    WARN_ON(hba->utmrdl_dma_addr & (PAGE_SIZE - 1))) {
> +	    WARN_ON(hba->utmrdl_dma_addr & (1024 - 1))) {
>  		dev_err(hba->dev,
>  		"Task Management Descriptor Memory allocation failed\n");
>  		goto out;
> -- 
> 2.25.1
> 

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2023-02-01 10:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01  3:49 [PATCH] scsi: ufs: core: Limit DMA alignment check Bjorn Andersson
2023-02-01 10:27 ` Manivannan Sadhasivam [this message]
2023-02-01 16:28   ` Bjorn Andersson
2023-02-02 18:01     ` Manivannan Sadhasivam
2023-02-01 17:20 ` Bart Van Assche
2023-02-01 17:59 ` Asutosh Das
2023-02-08 23:45 ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230201102748.GA62808@thinkpad \
    --to=mani@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=quic_asutoshd@quicinc.com \
    --cc=quic_bjorande@quicinc.com \
    --cc=stanley.chu@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.