linux-kernel - Re: [PATCH 1/4] dmaengine: qcom: 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8dfa8ba1-6e98-a8e4-614c-592861cef571@linaro.org>
Date:   Mon, 22 Jan 2018 09:55:01 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Vinod Koul <vinod.koul@...el.com>
Cc:     Andy Gross <andy.gross@...aro.org>, dmaengine@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        David Brown <david.brown@...aro.org>,
        Dan Williams <dan.j.williams@...el.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        yanhe@...cinc.com, ramkri@....qualcomm.com, sdharia@...cinc.com
Subject: Re: [PATCH 1/4] dmaengine: qcom: bam_dma: make bam clk optional



On 19/01/18 05:52, Vinod Koul wrote:
> On Tue, Jan 16, 2018 at 07:02:33PM +0000, srinivas.kandagatla@...aro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>>
>> When BAM is remotely controlled it does not sound correct to control
>> its clk on Linux side. Make it optional, so that its not madatory
> 
> s/madatory/mandatory
> 
Yep,
>> for remote controlled BAM instances.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>> ---
>>   drivers/dma/qcom/bam_dma.c | 15 ++++++++-------
>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>> index 03c4eb3fd314..78e488e8f96d 100644
>> --- a/drivers/dma/qcom/bam_dma.c
>> +++ b/drivers/dma/qcom/bam_dma.c
>> @@ -1180,13 +1180,14 @@ static int bam_dma_probe(struct platform_device *pdev)
>>   						"qcom,controlled-remotely");
>>   
>>   	bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
> 
> but you still do clk_get unconditionally?

Only reason to do this way is to not break existing users in the mainline.

remotely controlled BAM is already supported in upstream driver, there 
are users of this who pass clk from device tree, If I make this 
conditional then subsequent reads to the BAM registers for those 
instances might crash the system.

This sounds wrong to control clk from linux for the dma controller which 
is remotely controlled. These users should be transitioned to new 
bindings once the new bindings endup in the mainline.

> 
>> -	if (IS_ERR(bdev->bamclk))
>> -		return PTR_ERR(bdev->bamclk);
>> -
>> -	ret = clk_prepare_enable(bdev->bamclk);
>> -	if (ret) {
>> -		dev_err(bdev->dev, "failed to prepare/enable clock\n");
>> -		return ret;
>> +	if (IS_ERR(bdev->bamclk)) {
>> +		bdev->bamclk = NULL;
>> +	} else {
>> +		ret = clk_prepare_enable(bdev->bamclk);
>> +		if (ret) {
>> +			dev_err(bdev->dev, "failed to prepare/enable clock\n");
>> +			return ret;
>> +		}
> 
> wouldn't it be better to set that an instance is remote controlled and thus
> not at all visible to Linux?

We already have a flag "controlled_remotely" for that in the driver.

thanks,
srini
> 
>>   	}
>>   
>>   	ret = bam_init(bdev);
>> -- 
>> 2.15.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>