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]
Date: Sun, 17 Dec 2023 13:18:59 +0200
From: Péter Ujfalusi <peter.ujfalusi@...il.com>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: vkoul@...nel.org, dmaengine@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 srk@...com, vigneshr@...com
Subject: Re: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to
 request TX channel by ID



On 15/12/2023 08:08, Siddharth Vadapalli wrote:
>>>  err:
>>> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>>>  }
>>>  EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
>>>  
>>> +struct k3_udma_glue_tx_channel *
>>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
>>> +				  struct device_node *udmax_np, u32 thread_id)
>>
>> udmax_np is not dev->of_node ?
> 
> I am not sure I fully understand the question. If you meant to ask if the driver
> which uses this API will not have its device's of_node set to udmax_np, then yes
> that's correct.
> 
> The driver shall be probed over RPMsg-bus, due to which its device's of_node
> will not be udmax_np. Additionally, the udmax_np is the device-tree node of one
> of the DMA Controllers described in the device-tree. The driver shall obtain the
> reference to the udmax_np node using the API:
> of_find_compatible_node()
> with the compatible to be passed to the above API being a part of the driver's
> data. Thus, it is possible to specify which DMA Controller to use by specifying
> the compatible in the driver's data. I hope that I have answered your question.
> Please let me know otherwise.

I see, thank you for the detailed explanation!

> Thank you for reviewing the series. I will rename the API as mentioned above and
> if the question you had above regarding the of_node has been addressed, I will
> post the v3 series. Kindly let me know.

I don't have other open issues, thanks for the updates

-- 
Péter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ