[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241223193130.GA2032@quark.localdomain>
Date: Mon, 23 Dec 2024 11:31:30 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Ram Kumar Dwivedi <quic_rdwivedi@...cinc.com>
Cc: manivannan.sadhasivam@...aro.org, James.Bottomley@...senpartnership.com,
martin.petersen@...cle.com, andersson@...nel.org,
bvanassche@....org, linux-arm-msm@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
Naveen Kumar Goud Arepalli <quic_narepall@...cinc.com>,
Nitin Rawat <quic_nitirawa@...cinc.com>
Subject: Re: [PATCH V6] scsi: ufs: qcom: Enable UFS Shared ICE Feature
On Mon, Dec 23, 2024 at 06:50:33PM +0530, Ram Kumar Dwivedi wrote:
> #ifdef CONFIG_SCSI_UFS_CRYPTO
> +/**
> + * ufs_qcom_config_ice_allocator() - ICE core allocator configuration
> + *
> + * @host: pointer to qcom specific variant structure.
> + */
> +static void ufs_qcom_config_ice_allocator(struct ufs_qcom_host *host)
> +{
> + struct ufs_hba *hba = host->hba;
> + static const uint8_t val[4] = { NUM_RX_R1W0, NUM_TX_R0W1, NUM_RX_R1W1, NUM_TX_R1W1 };
> + u32 config;
> +
> + if (!is_ice_config_supported(host))
> + return;
This is the only place that is_ice_config_supported() is called, so the helper
function seems unnecessary vs. just checking UFS_QCOM_CAP_ICE_CONFIG directly.
Also, shouldn't any ICE configuration also be conditional on UFSHCD_CAP_CRYPTO?
Just in case the ICE support got turned off for some reason.
- Eric
Powered by blists - more mailing lists