linux-kernel - Re: [PATCH 07/18] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API

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: <71d190e7-5654-e873-16b0-3b9bd6e8bf7a@ti.com>
Date:   Wed, 7 Oct 2020 11:22:55 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Vinod Koul <vkoul@...nel.org>
CC:     <nm@...com>, <ssantosh@...nel.org>, <robh+dt@...nel.org>,
        <vigneshr@...com>, <dan.j.williams@...el.com>, <t-kristo@...com>,
        <lokeshvutla@...com>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <dmaengine@...r.kernel.org>
Subject: Re: [PATCH 07/18] dmaengine: ti: k3-udma-glue: Add function to get
 device pointer for DMA API



On 07/10/2020 9.53, Vinod Koul wrote:
> On 30-09-20, 12:14, Peter Ujfalusi wrote:
>> Glue layer users should use the device of the DMA for DMA mapping and
>> allocations as it is the DMA which accesses to descriptors and buffers,
>> not the clients
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
>> ---
>>  drivers/dma/ti/k3-udma-glue.c    | 14 ++++++++++++++
>>  drivers/dma/ti/k3-udma-private.c |  6 ++++++
>>  drivers/dma/ti/k3-udma.h         |  1 +
>>  include/linux/dma/k3-udma-glue.h |  4 ++++
>>  4 files changed, 25 insertions(+)
>>
>> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
>> index a367584f0d7b..a53bc4707ae8 100644
>> --- a/drivers/dma/ti/k3-udma-glue.c
>> +++ b/drivers/dma/ti/k3-udma-glue.c
>> @@ -487,6 +487,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn)
>>  }
>>  EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq);
>>  
>> +struct device *
>> +	k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn)
> 
> How about..
> 
> struct device *
> k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn)

OK.

> 
>> +{
>> +	return xudma_get_device(tx_chn->common.udmax);
>> +}
>> +EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device);
> 
> Hmm why would you need to export this device.. Can you please outline
> all the devices involved here...

In upstream we have one user of the udma-glue layer:
drivers/net/ethernet/ti/am65-cpsw-nuss.c

It is allocating memory to be used with DMA (descriptor pool), it needs
to use correct device for DMA API.
The cpsw atm using it's own dev for allocation, which is wrong, but it
worked fine as am654/j721e/j7200 is all coherent.

> why not use dmaI_dev->dev or chan->dev?

The glue layer does not use DMAengine API to request a channel as it
require special resource setup compared to what is possible via generic
API. We have kept the DMAengine and Glue layer as separate until I have
time to extend the core to support the features we would need to remove
the Glue layer.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki