linux-kernel - Re: [RFC} arm architecture board/feature deprecation timeline

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: <20240801182313.GD47080@darkstar.musicnaut.iki.fi>
Date: Thu, 1 Aug 2024 21:23:13 +0300
From: Aaro Koskinen <aaro.koskinen@....fi>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Russell King <linux@...linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Richard Earnshaw <richard.earnshaw@....com>,
	Richard Sandiford <richard.sandiford@....com>,
	Ramana Radhakrishnan <ramanara@...dia.com>,
	Nicolas Pitre <nico@...xnic.net>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Mark Brown <broonie@...nel.org>,
	Kristoffer Ericson <kristoffer.ericson@...il.com>,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	Janusz Krzysztofik <jmkrzyszt@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	Nikita Shubin <nikita.shubin@...uefel.me>,
	linux-samsung-soc@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Gregory Clement <gregory.clement@...tlin.com>,
	"Jeremy J. Peper" <jeremy@...emypeper.com>,
	debian-arm@...ts.debian.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>
Subject: Re: [RFC} arm architecture board/feature deprecation timeline

Hi,

On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote:
> > These tablets are not very attractive for hobbyists anymore as the display
> > support got broken and eventually deleted due to bitrot. There has been
> > some out-of-tree patches/interest to regain display and other features,
> > but no major progress really in 10 years or so. The last major mainline
> > feature was adding Retu watchdog support that allowed the device to stay
> > on longer than 30 seconds after the boot (the hardware watchdog cannot
> > be disabled).
> >
> > I guess in OMAP-land N8x0 is one of the least used/active boards, so if
> > it causes "a lot of pain" then maybe could be a candidate for deprecation.
> > But with custom kernel config, the board has been pretty stable overall
> > between the releases for limited use cases.
> 
> Yes, I think it would help a lot to deprecate it, at least this
> would save me the work of moving ARMv6 into an ARMv5 compatible
> option (I have done the patches, but they are entirely untested
> on real hardware and probably incorrect).
> 
> Would the timing make any difference to you? I.e. does it help
> to keep another year or two, or would dropping it in early 2025
> be the same?

Early 2025 could come too soon, but anyway during 2025 sounds OK. Let's
see if anyone else has comments. At least one more LTS release where it
has been tested would be nice.

> We'd also want to coordinate this with the i.MX31 maintainers,
> since dropping both together is the only way to remove
> ARM1136r0 support.
> 
> >> === OMAP1 ===
> >> 
> >> This is now the only ARMv4T/ARMv5 platform with no
> >> DT support, making it a target for removal at some
> >> point. Unlike PXA, there are still users, but it seems
> >> there are no current plans for a DT conversion.
> >> 
> >> I would suggest going through the five boards
> >> individually to see which ones we can remove in 2025
> >> and keep the remaining ones for the moment.
> >
> > Here situation hasn't changed - all of the boards are equally
> > important/useful, at least from a maintainer point of view. The routine
> > I use to test/debug kernel releases relies on all of them.
> 
> Ok, noted. Since you are doing the testing, that at least means
> we have a chance of cleaning up the code gradually towards using
> DT. Dmitry has started a migration of platform_data towards
> DT compatible device properties, which can be done gradually
> for the 22 platform drivers you use. This unfortunately still
> leaves the nonstandard dmaengine interface (for UDC), but we
> can deal with that later.

I have some plans to work on that. There's a long-standing bug with 15xx
DMA, but I have gotten that working, just need send those fixes out. After
that the conversion to new dmaengine should be more straightforward,
as we have a working testable reference for both boards using the UDC.

A.