linux-kernel - Re: [PATCH v2] dmaengine: Create symlinks between DMA channels and slaves

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:   Fri, 24 Jan 2020 09:31:23 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Vinod Koul <vkoul@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Dan Williams <dan.j.williams@...el.com>,
        <dmaengine@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] dmaengine: Create symlinks between DMA channels and
 slaves

Vinod, Geert,

On 24/01/2020 8.13, Vinod Koul wrote:
> On 22-01-20, 15:10, Vinod Koul wrote:
> 
>> I like the idea of adding this in debugfs and giving more info, I would
>> actually love to add bytes_transferred and few more info (descriptors
>> submitted etc) to it...
>>
>>>> This way we will have all the information in one place, easy to look up
>>>> and you don't need to manage symlinks dynamically, just check all
>>>> channels if they have slave_device/name when they are in_use (in_use w/o
>>>> slave_device is 'non slave')
>>>>
>>>> Some drivers are requesting and releasing the DMA channel per transfer
>>>> or when they are opened/closed or other variations.
>>>>
>>>>> What do other people think?
>>>
>>> Vinod: do you have some guidance for your minions? ;-)
>>
>>
>> That said, I am not against merging this patch while we add more
>> (debugfs)... So do my minions agree or they have better ideas :-)
> 
> So no new ideas, I am going to apply this and queue for 5.6, something
> is better than nothing.

My only issue with the symlink is that it is created/removed on some
setups quite frequently as they request/release channel per transfer or
open/close.
It might be a small hit in performance, but it is going to be for them.

> And I am looking forward for debugfs to give better picture, volunteers?

Well, I still feel that the debugfs can give better view in one place
and in production it can be disabled to save few bytes per channel and
code is not complied in.

If we have the debugfs we can remove some of the sysfs devices files
probably.

gpiolib have a nice implementation for us to lift and adapt.

- Péter

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