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]
Message-ID: <f931da29-5f10-494a-acc0-309bd805d41a@microchip.com>
Date: Fri, 12 Sep 2025 18:49:31 +0200
From: Nicolas Ferre <nicolas.ferre@...rochip.com>
To: Arnd Bergmann <arnd@...db.de>, <ksummit@...ts.linux.dev>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <linux-mips@...r.kernel.org>,
	<linux-mm@...ck.org>, <imx@...ts.linux.dev>, Christophe Leroy
	<christophe.leroy@...roup.eu>, Richard Weinberger <richard@....at>, "Lucas
 Stach" <l.stach@...gutronix.de>, Linus Walleij <linus.walleij@...aro.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>, Ankur Arora
	<ankur.a.arora@...cle.com>, David Hildenbrand <david@...hat.com>, "Mike
 Rapoport" <rppt@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Matthew Wilcox <willy@...radead.org>, Andrew Morton
	<akpm@...ux-foundation.org>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Suren Baghdasaryan <surenb@...gle.com>,
	"Ira Weiny" <ira.weiny@...el.com>, Nishanth Menon <nm@...com>,
	Heiko Stübner <heiko@...ech.de>, Alexander Sverdlin
	<alexander.sverdlin@...il.com>, "Chester A. Unal"
	<chester.a.unal@...nc9.com>, Sergio Paracuellos
	<sergio.paracuellos@...il.com>, Andreas Larsson <andreas@...sler.com>, "Mihai
 Sain" <Mihai.Sain@...rochip.com>, Alexandre Belloni
	<alexandre.belloni@...tlin.com>, Claudiu Beznea <claudiu.beznea@...on.dev>
Subject: Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

Arnd,

On 09/09/2025 at 23:23, Arnd Bergmann wrote:
> I'm still collecting information about which of the remaining highmem
> users plan to keep updating their kernels and for what reason.

We have 1GB of memory on our latest Cortex-A7 SAMA7D65 evaluation boards 
[1] (full production announced beg. 2025). The wide range of DDR types 
supported make some of these types interesting to use at such density.
Both our Cortex-A7 SoCs don't have IOMMU; core and DMAs can address the 
full range of the 32 bit address space, so we're quite 
standard/simplistic in this area. We use CMA with large chunks as our 
camera or display interfaces address "modern-ish" resolutions (~1080p).

We use CONFIG_HIGHMEM and activated it for simplicity, conformance to 
usual user-space workloads and planned to add it to our sama7_defconfig 
[2]. I understand that we might reconsider this "by default" choice and 
move to one of the solutions you highlighted in your message, lwn.net 
article or recent talk at ELC-E.

Of course we plan to maintain these boards and keep updating our kernel 
"offer" once a year for those associated SoCs (with maintaining 
upstream, as usual). As you said, being ARMv7, we're quite confident for 
now.

As you mentioned, we've recently released one ARMv5te arm926ejs-based 
soc: the SAM9x75 family. But we don't have the intention to use too big 
memory sizes on them, even if they do address large screens, with LVDS 
and MIPI or modern camera interfaces...

I don't have too much info about our customer's use cases as they are 
very, very diverse, but don't hesitate to reach out to me if you have 
questions about a particular combination of use.
Thanks for your regular update on these topics.

Best regards,
   Nicolas

[1]: for instance: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts#n29

[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/sama7_defconfig

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ