linux-kernel - Re: [PATCH] dmaengine: qcom: bam_dma: Fix BAM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1a5fc7e9-39fe-e527-efc3-1ea990bbb53b@quicinc.com>
Date: Fri, 10 Jan 2025 16:38:18 +0530
From: Md Sadre Alam <quic_mdalam@...cinc.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
CC: <vkoul@...nel.org>, <ulf.hansson@...aro.org>, <robin.murphy@....com>,
        <kees@...nel.org>, <u.kleine-koenig@...libre.com>,
        <linux-arm-msm@...r.kernel.org>, <av2082000@...il.com>,
        <dmaengine@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <djakov@...nel.org>, <quic_varada@...cinc.com>,
        <quic_srichara@...cinc.com>
Subject: Re: [PATCH] dmaengine: qcom: bam_dma: Fix BAM_RIVISON register
 handling



On 1/10/2025 3:45 PM, Stephan Gerhold wrote:
> On Fri, Jan 10, 2025 at 10:44:09AM +0530, Md Sadre Alam wrote:
>> This patch fixes a bug introduced in the previous commit where the
>> BAM_DESC_CNT_TRSHLD register was conditionally written based on BAM-NDP
>> mode. Additionally, it addresses an issue where reading the BAM_REVISION
>> register hangs if num-ees is not zero. A check has been added to prevent
>> this.
>>
>> Cc: stable@...r.kernel.org
>> Fixes: 57a7138d0627 ("dmaengine: qcom: bam_dma: Avoid writing unavailable register")
>> Reported-by: Georgi Djakov <djakov@...nel.org>
>> Link: https://lore.kernel.org/lkml/9ef3daa8-cdb1-49f2-8d19-a72d6210ff3a@kernel.org/
>> Signed-off-by: Md Sadre Alam <quic_mdalam@...cinc.com>
>> ---
>>   drivers/dma/qcom/bam_dma.c | 23 ++++++++++++++++-------
>>   1 file changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>> index c14557efd577..2b88b27f2f91 100644
>> --- a/drivers/dma/qcom/bam_dma.c
>> +++ b/drivers/dma/qcom/bam_dma.c
>> @@ -445,11 +445,15 @@ static void bam_reset(struct bam_device *bdev)
>>   	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
>>   
>>   	/* set descriptor threshold, start with 4 bytes */
>> -	if (in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
>> -		     BAM_NDP_REVISION_END))
>> +	if (!bdev->num_ees && in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
>> +				       BAM_NDP_REVISION_END))
>>   		writel_relaxed(DEFAULT_CNT_THRSHLD,
>>   			       bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
>>   
>> +	if (bdev->num_ees && !bdev->bam_revision)
>> +		writel_relaxed(DEFAULT_CNT_THRSHLD, bam_addr(bdev, 0,
>> +							     BAM_DESC_CNT_TRSHLD));
>> +
>>   	/* Enable default set of h/w workarounds, ie all except BAM_FULL_PIPE */
>>   	writel_relaxed(BAM_CNFG_BITS_DEFAULT, bam_addr(bdev, 0, BAM_CNFG_BITS));
>>   
>> @@ -1006,10 +1010,14 @@ static void bam_apply_new_config(struct bam_chan *bchan,
>>   			maxburst = bchan->slave.src_maxburst;
>>   		else
>>   			maxburst = bchan->slave.dst_maxburst;
>> -		if (in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
>> -			     BAM_NDP_REVISION_END))
>> +		if (!bdev->num_ees && in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
>> +					       BAM_NDP_REVISION_END))
>>   			writel_relaxed(maxburst,
>>   				       bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
>> +
>> +		if (bdev->num_ees && !bdev->bam_revision)
>> +			writel_relaxed(DEFAULT_CNT_THRSHLD, bam_addr(bdev, 0,
>> +								     BAM_DESC_CNT_TRSHLD));
> 
> I guess you meant writel_relaxed(maxburst, ...) here?
> 
> This patch is quite confusing. We shouldn't duplicate the register
> writes here just to have different handling for if (bdev->num_ees) and
> if (!bdev->num_ees).
> 
> Also, num-ees is unrelated to the question if the BAM is BAM-NDP or
> BAM-Lite. Typically we specify qcom,num-ees in the device tree for a BAM
> if the BAM is either:
> 
>   - Controlled remotely (= powered on and initialized outside of Linux)
>     This is the case for the SLIMbus BAM Georgi mentioned.
> 
>   - Powered remotely (= powered on outside of Linux, but must be
>     initialized inside Linux)
> 
> Reading BAM_REVISION in these cases will hang in bam_init(), because we
> cannot guarantee the BAM is already powered on when the bam_dma driver
> is being loaded in Linux. We need to delay reading the register until
> the BAM is up.
> 
> Given that these writes happen only for the !bdev->controlled_remotely
> case, you could fix this more cleanly by reading the BAM revision inside
> bam_reset().
Thank you for review and suggestion. Will clean up in next revision.

Thanks,
Alam.