linux-kernel - Re: [RFC 2/2] drivers: dma-mapping: parse per device reserved mem at probe time

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]

Date:   Thu, 07 Dec 2017 13:01:45 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Peng Fan <van.freenix@...il.com>
Cc:     Peng Fan <peng.fan@....com>, hch@....de, robin.murphy@....com,
        gregkh@...uxfoundation.org, robh+dt@...nel.org,
        frowand.list@...il.com, iommu@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [RFC 2/2] drivers: dma-mapping: parse per device reserved mem
 at probe time

Hi Peng,

On 2017-11-27 10:04, Peng Fan wrote:
> On Mon, Nov 27, 2017 at 09:44:20AM +0100, Marek Szyprowski wrote:
>> On 2017-11-27 09:37, Peng Fan wrote:
>>> On Mon, Nov 27, 2017 at 09:31:00AM +0100, Marek Szyprowski wrote:
>>>> On 2017-11-26 14:13, Peng Fan wrote:
>>>>> Invoke of_reserved_mem_device_init at dma_configure, then
>>>>> there is no need to call of_reserved_mem_device_init in device
>>>>> specific probe function.
>>>>>
>>>>> Signed-off-by: Peng Fan <peng.fan@....com>
>>>> This has been already tried long time ago, without success:
>>>> http://patches.linaro.org/patch/33558/
>>> Thanks for the info. I should first search mail list before
>>> sending out patches.
>> It doesn't mean that I'm against such idea. I just pointed that I've
>> already tried. That time, however there was no dma_configure() function
>> yet, which seems to be better place for of_rmem_device_init().
>>
>> I would however always call of_dma_configure(), even when reserved mem
>> node is there. IIRC on ARM64 that function configures dma_ops, without
>> which no dma is possible at all.
> So, you prefer this?
> 	if (dma_dev->of_node) {
> +		of_reserved_mem_device_init(dev);
> 		ret = of_dma_configure(dev, dma_dev->of_node);
>
> However in of_reserved_mem_device, there is also an call to
> of_dma_configure.
>
> "
> 	/* ensure that dma_ops is set for virtual devices
> 	 * using reserved memory
> 	 */
> 	 ret = of_dma_configure(dev, np);
> "
>
> If always call of_dma_configure, of_dma_configure maybe called twice.

Right, I forgot about this.

> I just checked more. of_reserved_mem_device_init only handle the first
> memory-region. To nodes which have multiple memory-region, seems 2nd and etc
> could not be handled, such as drivers/media/platform/s5p-mfc/s5p_mfc.c.

Well, maybe automatic assignment should be done only when there is only
one reserved region set? In case more than one region assigned to a device,
the driver has to create virtual child devices and configure DMA for them
to be able to let dma-mapping API to use those reserved regions. It looks
that the call to of_dma_configure(dev, np) can be moved back to the driver
(it was not possible at the time that code was merged due to missing
export symbols).

Configuring more than one reserved memory region for given device might
then moved to some helper function to have a common code for that across
the drivers.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland