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: <0ca5b09d-13f6-4ea8-8a25-a189f1875a75@app.fastmail.com>
Date: Fri, 02 Aug 2024 14:53:48 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Aaro Koskinen" <aaro.koskinen@....fi>
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

On Thu, Aug 1, 2024, at 20:23, Aaro Koskinen wrote:
> On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote:
>> 
>> 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.

To be clear: with "early 2025" I meant after the next LTS release
(6.12 as it seems), but one LTS later (early 2026) is still a
good outlook.

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

Nice, that does give a realistic hope of eventually doing a full
DT conversion then. If we manage to do both the DMA engine and
the device properties work, I would hope that writing an equivalent
dts file gets fairly easy.

     Arnd