linux-kernel - Re: [PATCH 3/4] usb: remove OMAP USB Device Controller and OHCI support for OMAP1/2 chips

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:   Fri, 13 Jan 2023 09:14:30 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Aaro Koskinen <aaro.koskinen@....fi>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Janusz Krzysztofik <jmkrzyszt@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        linux-usb@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] usb: remove OMAP USB Device Controller and OHCI
 support for OMAP1/2 chips

* Arnd Bergmann <arnd@...db.de> [230112 14:31]:
> On Thu, Jan 12, 2023, at 15:05, Aaro Koskinen wrote:
> > On Thu, Jan 12, 2023 at 11:19:53AM +0100, Arnd Bergmann wrote:
> >> On Thu, Jan 12, 2023, at 10:53, Tony Lindgren wrote:
> >> 
> >> So if we want to kill off the old DMA stuff there is actually
> >> a choice between either making omap_udc PIO-only or converting
> >> it to use the standard dmaengine interface.
> >
> > I use this driver on Palm TE and 770, and without it those boards would
> > be useless for my use cases. Also DMA doubles the throughput, probably
> > also power usage is smaller.
> 
> Ok, if the performance is important, converting to dmaengine
> is probably best. Do you know if this is just a straightforward
> replacement of the function calls, or are there technical reasons
> why it's not using the dmaengine interface yet?

Yes I agree dmaengine is the best solution. Seems like this is the
last driver using the old api that never got updated probably because
it's not used on the newer SoCs.

I don't think there are any technical reasons to not use dmaengine
here.

FYI, the last blocker for dmaengine use was for drivers using
port_window that got added with the drivers/usb/musb/tusb6010_omap.c
dmaengine conversion a few years back.

Regards,

Tony