linux-kernel - Re: [PATCH 0/3] Add global CMA reserve area

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D1ZXO8F3XN2I.3CTTE245I0TYY@ti.com>
Date: Fri, 14 Jun 2024 12:58:22 -0500
From: Randolph Sapp <rs@...com>
To: Devarsh Thakkar <devarsht@...com>, <nm@...com>, <vigneshr@...com>,
        <kristo@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC: <praneeth@...com>, <a-bhatia1@...com>, <j-luthra@...com>,
        <b-brnich@...com>, <detheridge@...com>, <p-mantena@...com>,
        <vijayp@...com>
Subject: Re: [PATCH 0/3] Add global CMA reserve area

On Thu Jun 13, 2024 at 10:08 AM CDT, Devarsh Thakkar wrote:
> Add global CMA reserve area for AM62x, AM62A and AM62P SoCs.
> These SoCs do not have MMU and hence require contiguous memory pool to
> support various multimedia use-cases.
>
> Brandon Brnich (1):
>   arm64: dts: ti: k3-am62p5-sk: Reserve 576 MiB of global CMA
>
> Devarsh Thakkar (2):
>   arm64: dts: ti: k3-am62x-sk-common: Reserve 128MiB of global CMA
>   arm64: dts: ti: k3-am62a7-sk: Reserve 576MiB of global CMA
>
>  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts        | 9 +++++++++
>  arch/arm64/boot/dts/ti/k3-am62p5-sk.dts        | 7 +++++++
>  arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 8 ++++++++
>  3 files changed, 24 insertions(+)

I'm still a little torn about putting this allocation into the device tree
directly as the actual required allocation size depends on the task.

If it's allowed though, this series is fine for introducing those changes. This
uses the long-tested values we've been using on our tree for a bit now. The only
thing that's a little worrying is the missing range definitions for devices with
more than 32bits of addressable memory as Brandon has pointed out. Once that's
addressed:

Reviewed-by: Randolph Sapp <rs@...com>

Specifying these regions using the kernel cmdline parameter via u-boot was
brought up as a potential workaround. This is fine until you get into distro
boot methods which will almost certainly attempt to override those. I don't
know. Still a little odd. Curious how the community feels about it.

Technically the user or distro can still override it with the cmdline parameter
if necessary, so this may be the best way to have a useful default.