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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Jan 2020 07:30:01 -0800
From:   Olof Johansson <olof@...om.net>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     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>,
        Arnd Bergmann <arnd@...db.de>, SoC Team <soc@...nel.org>
Subject: Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver

On Mon, Jan 27, 2020 at 2:31 AM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
>
> Hi Olof,
>
> On 24/01/2020 22.08, Olof Johansson wrote:
> > On Fri, Jan 24, 2020 at 11:23:59AM +0200, Peter Ujfalusi wrote:
> >> The UDMA driver is used on K3 platforms (am654 and j721e).
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
> >> ---
> >> Hi,
> >>
> >> The drivers for UDMA are already in linu-next and the DT patches are going to be
> >> also heading for 5.6.
> >> The only missing piece is to enable the drivers in defconfig so clients can use
> >> the DMA.
> >
> > Hi Peter,
> >
> > We normally like to see new options turned on after the driver/option has been
> > merged, so send this during or right after the merge window when that happens,
> > please.
>
> Sure, I'll post it later.

Great!

>
> > 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".

I find it useful to challenge most of the =y drivers to make people
think about it, and at some point we'll enough overhead of cruft in
the static superset kernel that defconfig today is used for such that
we need to prune more =y -> =m, but this particular driver is probably
OK (it's also not large).

> Imho module would be fine for the DMA stack, but neither ringacc or the
> UDMA driver can be built as module atm until the following patches got
> merged:
> https://lore.kernel.org/lkml/20200122104723.16955-1-peter.ujfalusi@ti.com/
> https://lore.kernel.org/lkml/20200122104031.15733-1-peter.ujfalusi@ti.com/
>
> I have the patches to add back module support, but waiting on these
> currently.

-Olof