[PATCH RFC 00/20] ARM: oxnas support removal
arnd at arndb.de
Fri Mar 31 06:42:15 PDT 2023
On Fri, Mar 31, 2023, at 10:34, Neil Armstrong wrote:
> With  removing MPCore SMP support, this makes the OX820 barely usable,
> associated with a clear lack of maintainance, development and migration to
> dt-schema it's clear that Linux support for OX810 and OX820 should be removed.
> In addition, the OX810 hasn't been booted for years and isn't even present
> in an ARM config file.
> For the OX820, lack of USB and SATA support makes the platform not usable
> in the current Linux support and relies on off-tree drivers hacked from the
> vendor (defunct for years) sources.
> The last users are in the OpenWRT distribution, and today's removal means
> support will still be in stable 6.1 LTS kernel until end of 2026.
> If someone wants to take over the development even with lack of SMP, I'll
> be happy to hand off maintainance.
> The plan is to apply the first 4 patches first, then the drivers
> followed by bindings. Finally the MAINTAINANCE entry can be removed.
> I'm not sure about the process of bindings removal, but perhaps the bindings
> should be marked as deprecated first then removed later on ?
> It has been a fun time adding support for this architecture, but it's time
> to get over!
> Patch 2 obviously depends on .
>  https://email@example.com/
> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
Thanks a lot for going through this and preparing the patches!
I've discussed this with Daniel Golle on the OpenWRT channel as well,
and he indicated that the timing is probably fine here, as there are
already close to zero downloads for oxnas builds, and the 6.1 kernel
will only be part of a release in 2024.
For the dependency on my other patch, I'd suggest you instead
remove the SMP files here as well, which means we can merge either
part independently based on just 6.3-rc. I can do that change
myself by picking up patches 1-4 of your RFC series, or maybe you
can send resend them after rebase to 6.3-rc1.
For the driver removals, I think we can merge those at the same
time as the platform removal since there are no shared header files
that would cause build time regressions and there are no runtime
regressions other than breaking the platform itself. Maybe
just send the driver removal separately to the subsystem
maintainers with my
Acked-by: Arnd Bergmann <arnd at arndb.de>
More information about the linux-mtd