linux-kernel - Re: [PATCH v6 2/4] dmaengine: tegra: Add tegra gpcdma driver

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: <bd4036f2-2ec2-1301-0956-42626ad3e12e@nvidia.com>
Date:   Thu, 23 Sep 2021 14:20:30 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Akhil R <akhilrajeev@...dia.com>
CC:     "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        Krishna Yarlagadda <kyarlagadda@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        Rajesh Gumasta <rgumasta@...dia.com>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        Pavan Kunapuli <pkunapuli@...dia.com>
Subject: Re: [PATCH v6 2/4] dmaengine: tegra: Add tegra gpcdma driver


On 23/09/2021 13:51, Akhil R wrote:
>> On 22/09/2021 15:46, Akhil R wrote:
>>>
>>>> On 17/09/2021 15:11, Akhil R wrote:
>>>>> +static int tegra_dma_slave_config(struct dma_chan *dc,
>>>>> +				  struct dma_slave_config *sconfig) {
>>>>> +	struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
>>>>> +
>>>>> +	if (tdc->dma_desc) {
>>>>> +		dev_err(tdc2dev(tdc), "Configuration not allowed\n");
>>>>> +		return -EBUSY;
>>>>> +	}
>>>>> +
>>>>> +	memcpy(&tdc->dma_sconfig, sconfig, sizeof(*sconfig));
>>>>> +	if (tdc->slave_id == -1)
>>>>> +		tdc->slave_id = sconfig->slave_id;
>>>>> +
>>>>> +	tdc->config_init = true;
>>>>> +	return 0;
>>>>> +}
>>>>
>>>> So you have a function to reserve a slave ID, but you don't check
>>>> here if it is already reserved.
>>> slave-id is reserved considering the direction as well.
>>> 'direction' is available only during prep_slave_sg function, I guess.
>>
>> Sorry I don't understand what you mean by that.
> I mean, it would not be possible to check if the sid is in use without knowing
> if the direction is MEM_TO_DEV or DEV_TO_MEM. The bitmask to check the
> sid reservation is separate for MEM_TO_DEV and DEV_TO_MEM.
> To get the direction parameter, we would need to wait till dma_prep_slave_sg
> is called, I guess. I saw in the documentation that the 'direction' element in
> dma_slave_config struct is deprecated and should use the value passed to
> dma_prep_slave_sg().

Do we even need to worry about slave_id here? Typically the slave_id is 
coming from device-tree and so is handled by tegra_dma_of_xlate(). I 
would drop this unless there is an actual use-case we need to support 
that uses this.

Jon

-- 
nvpublic