Re: [PATCH] scsi: ufs: exynos: fix programming of HCI_UTRL_NEXUS_TYPE

[Bart Van Assche <bvanassche@acm.org>]

On 7/7/25 10:05 AM, André Draszik wrote:
> On Google gs101, the number of UTP transfer request slots (nutrs) is
> 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE
> incorrectly as 0.
> 
> This is because the left hand side of the shift is 1, which is of type
> int, i.e. 31 bits wide. Shifting by more than that width results in
> undefined behaviour.
> 
> Fix this by switching to the BIT() macro, which applies correct type
> casting as required. This ensures the correct value is written to
> UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift
> warning:
>      UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21
>      shift exponent 32 is too large for 32-bit type 'int'
> 
> For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE
> write.
> 
> Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs")
> Cc: stable@vger.kernel.org
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
>   drivers/ufs/host/ufs-exynos.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
> index 3e545af536e53e06b66c624ed0dc6dc7de13549f..f0adcd9dd553d2e630c75e8c3220e21bc5f7c8d8 100644
> --- a/drivers/ufs/host/ufs-exynos.c
> +++ b/drivers/ufs/host/ufs-exynos.c
> @@ -1110,8 +1110,8 @@ static int exynos_ufs_post_link(struct ufs_hba *hba)
>   	hci_writel(ufs, val, HCI_TXPRDT_ENTRY_SIZE);
>   
>   	hci_writel(ufs, ilog2(DATA_UNIT_SIZE), HCI_RXPRDT_ENTRY_SIZE);
> -	hci_writel(ufs, (1 << hba->nutrs) - 1, HCI_UTRL_NEXUS_TYPE);
> -	hci_writel(ufs, (1 << hba->nutmrs) - 1, HCI_UTMRL_NEXUS_TYPE);
> +	hci_writel(ufs, BIT(hba->nutrs) - 1, HCI_UTRL_NEXUS_TYPE);
> +	hci_writel(ufs, BIT(hba->nutmrs) - 1, HCI_UTMRL_NEXUS_TYPE);
>   	hci_writel(ufs, 0xf, HCI_AXIDMA_RWDATA_BURST_LEN);
>   
>   	if (ufs->opts & EXYNOS_UFS_OPT_SKIP_CONNECTION_ESTAB)

Reviewed-by: Bart Van Assche <bvanassche@acm.org>