linux-kernel - Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver

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]

Message-ID: <CAK8P3a0Y2LAGPT8qtk51MxbsXjf8nHBbA7E1CvWcSgNi8UNNEA@mail.gmail.com>
Date:   Wed, 25 Mar 2020 15:57:08 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     Olof Johansson <olof@...om.net>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tero Kristo <t-kristo@...com>, Vinod Koul <vkoul@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        SoC Team <soc@...nel.org>
Subject: Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver

On Tue, Jan 28, 2020 at 9:20 AM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
> On 27/01/2020 17.30, Olof Johansson wrote:
> >>> I also see that this is statically enabling this driver -- we try to keep as
> >>> many drivers as possible as modules to avoid the static kernel from growing too
> >>> large. Would that be a suitable approach here, or is the driver needed to reach
> >>> rootfs for further module loading?
> >>
> >> We would need built in DMA for nfs rootfs, SD/MMC has it's own buit-in
> >> ADMA. We do not have network drivers upstream as they depend on the DMA.
> >
> > Ok, so that can either be turned into a ramdisk argument, or into a
> > "we really want to enable non-ramdisk rootfs boots on this hardware
> > because it's a common use case".
>
> SD/MMC does not need slave DMA, it is self containing with it's own
> built-in DMA.
> I'm not sure if it is enabled in defconfig. It is not enabled at all in
> defconfig atm.
>
> Normally I would use nfs rootfs, but we don't have network drivers
> upstream for K3 platform.
>
> I think having the UDMA stack as module should be fine when I have the
> dependencies in to be able to build them as modules.

Picking up this thread as I noticed the patch is still marked as 'New'
in patchwork.

I see no problem making this driver built-in at all if you want to
respin it.

> > but this particular driver is probably
> > OK (it's also not large).
>
> Well, it depends how you look at it ;)
>
> UDMA stack is not enabled in defconfig (w/o this patch):
> $ size vmlinux
> text      data     bss     dec       hex      filename
> 17853717  9221872  469288  27544877  1a44d2d  vmlinux
>
> UDMA stack is enabled in defconfig (w this patch):
> $ size vmlinux
> text      data     bss     dec       hex      filename
> 17890970  9237544  469288  27597802  1a51bea  vmlinux
>
> It would be nice for other driver to enable the DMA if it is acceptable
> to have it built in for start and when I can build it as module we can
> switch it to module?

In general, I'd prefer to avoid listing references to other drivers
in Kconfig when those are only runtime dependencies rather than
compile-time.

If the network driver just uses the generic dma slave API, then
I would not add a 'depends on' or 'select' for the particular DMA
engine that it uses, unless it relies on nonstandard exported
functions from that driver. Just enable both as modules and have
the runtime module loading along with deferred probe figure out
runtime dependency.

       Arnd