Scheduling (unused) board file removal for linux-6.x

Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

With the multiplatform work completed in the past merge window, and the
scheduled deprecation of the Samsung s3c platforms, I decided to have a
look at the remaining board files. There are 196 remaining boards, down
from 489 boards ten years ago, but my estimate is that only few of those
ever booted a linux-5.x kernel, and even less for future kernels. The
question is how to find out which ones are still used, and which ones
can go.

I would propose that we start by changing the assumption that all boards
might be used, instead assuming that they are all outdated unless someone
says that they actually prefer to keep it in the kernel.  I have started
a list of all 196 boards and annotated the ones that look like candidates
for removal [1]. If a board you use is on that list, please either reply
here or add a comment in the document.

Unless someone has a better idea for how to proceed, I would allow
six months for users to speak up and then remove the orphaned board
files for the release following the LTS kernel. I can't list all boards
individually, so here is a breakdown by platform:

s3c24xx

These are all scheduled for removal in early 2023 already, once the next
longterm stable kernel is out. No changes here, but it seems useful
to use the same timeline for removing unused board files of the other
platforms together.

s3c64xx

There are ten board files, which are currently scheduled for removal in
2024, along with the DT based boards for this SoC. We can still decide
to throw out some of the board files earlier though, while keeping the
platform around.

cns3xxx

There is only one reference board here, the actual products that were
previously supported, none of the board files from openwrt (now gone) made
it in, and the DT support was never completed, so the entire platform can
go away. We could also consider dropping the other arm11mpcore platforms
(oxnas and the mpcore variants of realview/integrator) at the same time,
since there are known issues with the CPU core.

iop32x

Some of the NAS devices were still in use two years ago as they have
a lot of RAM for an ARMv5 based machine, not sure if they still are
used. If they are, a DT conversion similar to what we did for ixp4xx
should be possible.

pxa

There are a ton of boards on this one, including seven with qemu support,
but based on IRC discussions, my feeling is that everyone who worked on
this has already lost interest a few years ago. There is rudimentary DT
support, so it may be helpful to pick one or two boards (gumstix?) with
good qemu support and keep them around for conversion to DT, while
removing all other boards.

mmp

This already has better DT support than pxa, at least for the ARMv7
based SoCs. The remaining nine board files are all candidates for removal.

sa1100

Similar to PXA, work on this appears to have stopped. Russell probably
still has an Assabet or some other machine, but I don't know if he
still plans to keep using new kernels on those. The only machine with
qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
then this should be kept as well. Probably no point doing a DT conversion
here though.

rpc

Russell is the only known user, and is likely to keep this one around
for as long as gcc can still build kernels (it needs gcc-8 or older).

footbridge

Three machines, most notably the NetWinder that a few people still have.
I assume Russell wants to keep the machines working that he still has.
ep93xx

These are still used, and the platform includes the only remaining two
board files that were added after linux-3.0. DT support is probably
doable now that common-clk works. Need information about which boards
are important.

omap1

common-clk and multiplatform support just landed. There are three boards
that are likely to be in use (ams-delta, osk and nokia770) and two boards
supported by qemu (sx1 and palmte), so we may want to keep those and
try to eventually convert them to DT. The rest can probably get retired.

davinci

DT conversion has stalled, and there are 12 remaining board files,
mostly for evaluation machines. No idea if any are still in use.

orion5x

DT conversion depends on stalled work for PCI. 16 boards never got
converted because of this, still enabled in Debian.  Can probably drop the
reference boards and the machines with less than 64MB. Debian_on_Buffalo
project apparently tries to keep these working, but there is also some
new interest in finishing DT conversion.

mv78xx0

Similar to orion5x, but lacking DT support completely. Only three
machines: one NAS and two reference design.

dove

Two board files, both of which have (incomplete) DT support as well.
Russell previously wanted to keep these around, not sure if he still
cares.

         Arnd

[1] https://docs.google.com/spreadsheets/d/1PL4dUUSieeXHzZhAn_Rnix32OTiCfN33sCQejpvI6ng/edit#gid=0

Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

With the multiplatform work completed in the past merge window, and the
scheduled deprecation of the Samsung s3c platforms, I decided to have a
look at the remaining board files. There are 196 remaining boards, down
from 489 boards ten years ago, but my estimate is that only few of those
ever booted a linux-5.x kernel, and even less for future kernels. The
question is how to find out which ones are still used, and which ones
can go.

I would propose that we start by changing the assumption that all boards
might be used, instead assuming that they are all outdated unless someone
says that they actually prefer to keep it in the kernel.  I have started
a list of all 196 boards and annotated the ones that look like candidates
for removal [1]. If a board you use is on that list, please either reply
here or add a comment in the document.

Unless someone has a better idea for how to proceed, I would allow
six months for users to speak up and then remove the orphaned board
files for the release following the LTS kernel. I can't list all boards
individually, so here is a breakdown by platform:

s3c24xx

These are all scheduled for removal in early 2023 already, once the next
longterm stable kernel is out. No changes here, but it seems useful
to use the same timeline for removing unused board files of the other
platforms together.

s3c64xx

There are ten board files, which are currently scheduled for removal in
2024, along with the DT based boards for this SoC. We can still decide
to throw out some of the board files earlier though, while keeping the
platform around.

cns3xxx

There is only one reference board here, the actual products that were
previously supported, none of the board files from openwrt (now gone) made
it in, and the DT support was never completed, so the entire platform can
go away. We could also consider dropping the other arm11mpcore platforms
(oxnas and the mpcore variants of realview/integrator) at the same time,
since there are known issues with the CPU core.

iop32x

Some of the NAS devices were still in use two years ago as they have
a lot of RAM for an ARMv5 based machine, not sure if they still are
used. If they are, a DT conversion similar to what we did for ixp4xx
should be possible.

pxa

There are a ton of boards on this one, including seven with qemu support,
but based on IRC discussions, my feeling is that everyone who worked on
this has already lost interest a few years ago. There is rudimentary DT
support, so it may be helpful to pick one or two boards (gumstix?) with
good qemu support and keep them around for conversion to DT, while
removing all other boards.

mmp

This already has better DT support than pxa, at least for the ARMv7
based SoCs. The remaining nine board files are all candidates for removal.

sa1100

Similar to PXA, work on this appears to have stopped. Russell probably
still has an Assabet or some other machine, but I don't know if he
still plans to keep using new kernels on those. The only machine with
qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
then this should be kept as well. Probably no point doing a DT conversion
here though.

rpc

Russell is the only known user, and is likely to keep this one around
for as long as gcc can still build kernels (it needs gcc-8 or older).

footbridge

Three machines, most notably the NetWinder that a few people still have.
I assume Russell wants to keep the machines working that he still has.
ep93xx

These are still used, and the platform includes the only remaining two
board files that were added after linux-3.0. DT support is probably
doable now that common-clk works. Need information about which boards
are important.

omap1

common-clk and multiplatform support just landed. There are three boards
that are likely to be in use (ams-delta, osk and nokia770) and two boards
supported by qemu (sx1 and palmte), so we may want to keep those and
try to eventually convert them to DT. The rest can probably get retired.

davinci

DT conversion has stalled, and there are 12 remaining board files,
mostly for evaluation machines. No idea if any are still in use.

orion5x

DT conversion depends on stalled work for PCI. 16 boards never got
converted because of this, still enabled in Debian.  Can probably drop the
reference boards and the machines with less than 64MB. Debian_on_Buffalo
project apparently tries to keep these working, but there is also some
new interest in finishing DT conversion.

mv78xx0

Similar to orion5x, but lacking DT support completely. Only three
machines: one NAS and two reference design.

dove

Two board files, both of which have (incomplete) DT support as well.
Russell previously wanted to keep these around, not sure if he still
cares.

         Arnd

[1] https://docs.google.com/spreadsheets/d/1PL4dUUSieeXHzZhAn_Rnix32OTiCfN33sCQejpvI6ng/edit#gid=0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hello Arnd!

On Wed, 2022-06-29 at 22:42 +0200, Arnd Bergmann wrote:
> ep93xx
> 
> These are still used, and the platform includes the only remaining two
> board files that were added after linux-3.0. DT support is probably
> doable now that common-clk works. Need information about which boards
> are important.

I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).

-- 
Alexander Sverdlin.

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hello Arnd!

On Wed, 2022-06-29 at 22:42 +0200, Arnd Bergmann wrote:
> ep93xx
> 
> These are still used, and the platform includes the only remaining two
> board files that were added after linux-3.0. DT support is probably
> doable now that common-clk works. Need information about which boards
> are important.

I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).

-- 
Alexander Sverdlin.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Rob Herring]

On Wed, Jun 29, 2022 at 2:44 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
>
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
>
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
>
> s3c24xx
>
> These are all scheduled for removal in early 2023 already, once the next
> longterm stable kernel is out. No changes here, but it seems useful
> to use the same timeline for removing unused board files of the other
> platforms together.
>
> s3c64xx
>
> There are ten board files, which are currently scheduled for removal in
> 2024, along with the DT based boards for this SoC. We can still decide
> to throw out some of the board files earlier though, while keeping the
> platform around.
>
> cns3xxx
>
> There is only one reference board here, the actual products that were
> previously supported, none of the board files from openwrt (now gone) made
> it in, and the DT support was never completed, so the entire platform can
> go away. We could also consider dropping the other arm11mpcore platforms
> (oxnas and the mpcore variants of realview/integrator) at the same time,
> since there are known issues with the CPU core.
>
> iop32x
>
> Some of the NAS devices were still in use two years ago as they have
> a lot of RAM for an ARMv5 based machine, not sure if they still are
> used. If they are, a DT conversion similar to what we did for ixp4xx
> should be possible.
>
> pxa
>
> There are a ton of boards on this one, including seven with qemu support,
> but based on IRC discussions, my feeling is that everyone who worked on
> this has already lost interest a few years ago. There is rudimentary DT
> support, so it may be helpful to pick one or two boards (gumstix?) with
> good qemu support and keep them around for conversion to DT, while
> removing all other boards.

FWIW, u-boot is removing all PXA support.

Rob

Re: Scheduling (unused) board file removal for linux-6.x

[Rob Herring]

On Wed, Jun 29, 2022 at 2:44 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
>
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
>
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
>
> s3c24xx
>
> These are all scheduled for removal in early 2023 already, once the next
> longterm stable kernel is out. No changes here, but it seems useful
> to use the same timeline for removing unused board files of the other
> platforms together.
>
> s3c64xx
>
> There are ten board files, which are currently scheduled for removal in
> 2024, along with the DT based boards for this SoC. We can still decide
> to throw out some of the board files earlier though, while keeping the
> platform around.
>
> cns3xxx
>
> There is only one reference board here, the actual products that were
> previously supported, none of the board files from openwrt (now gone) made
> it in, and the DT support was never completed, so the entire platform can
> go away. We could also consider dropping the other arm11mpcore platforms
> (oxnas and the mpcore variants of realview/integrator) at the same time,
> since there are known issues with the CPU core.
>
> iop32x
>
> Some of the NAS devices were still in use two years ago as they have
> a lot of RAM for an ARMv5 based machine, not sure if they still are
> used. If they are, a DT conversion similar to what we did for ixp4xx
> should be possible.
>
> pxa
>
> There are a ton of boards on this one, including seven with qemu support,
> but based on IRC discussions, my feeling is that everyone who worked on
> this has already lost interest a few years ago. There is rudimentary DT
> support, so it may be helpful to pick one or two boards (gumstix?) with
> good qemu support and keep them around for conversion to DT, while
> removing all other boards.

FWIW, u-boot is removing all PXA support.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Marc Zyngier]

On Wed, 29 Jun 2022 21:42:58 +0100,
Arnd Bergmann <arnd@kernel.org> wrote:
> 
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
> 
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
> 
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
> 

[...]

> pxa
> 
> There are a ton of boards on this one, including seven with qemu support,
> but based on IRC discussions, my feeling is that everyone who worked on
> this has already lost interest a few years ago. There is rudimentary DT
> support, so it may be helpful to pick one or two boards (gumstix?) with
> good qemu support and keep them around for conversion to DT, while
> removing all other boards.

For the two boards I used to maintain (Zeus and Viper), I'm happy to
see them go. Should anyone want to take over and bring them into this
decade, I'm happy to provide the HW I still have (although getting HW
was never a problem with PXA, and it probably is simply that people
have, just like I did, lost interest).

[...]

> footbridge
> 
> Three machines, most notably the NetWinder that a few people still have.
> I assume Russell wants to keep the machines working that he still has.

I still have a Netwinder that I switch on once in a while to check
that it is still alive (I last booted 5.18 on it, and maintain a
couple of ugly hacks to allow an old Debian to run on it). This isn't
a practical machine by any modern standard, but I'd like to keep it
around for the same reasons I still have an Alpha LCA4 (nostalgia).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: Scheduling (unused) board file removal for linux-6.x

[Marc Zyngier]

On Wed, 29 Jun 2022 21:42:58 +0100,
Arnd Bergmann <arnd@kernel.org> wrote:
> 
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
> 
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
> 
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
> 

[...]

> pxa
> 
> There are a ton of boards on this one, including seven with qemu support,
> but based on IRC discussions, my feeling is that everyone who worked on
> this has already lost interest a few years ago. There is rudimentary DT
> support, so it may be helpful to pick one or two boards (gumstix?) with
> good qemu support and keep them around for conversion to DT, while
> removing all other boards.

For the two boards I used to maintain (Zeus and Viper), I'm happy to
see them go. Should anyone want to take over and bring them into this
decade, I'm happy to provide the HW I still have (although getting HW
was never a problem with PXA, and it probably is simply that people
have, just like I did, lost interest).

[...]

> footbridge
> 
> Three machines, most notably the NetWinder that a few people still have.
> I assume Russell wants to keep the machines working that he still has.

I still have a Netwinder that I switch on once in a while to check
that it is still alive (I last booted 5.18 on it, and maintain a
couple of ugly hacks to allow an old Debian to run on it). This isn't
a practical machine by any modern standard, but I'd like to keep it
around for the same reasons I still have an Alpha LCA4 (nostalgia).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Tony Lindgren]

Hi,

* Arnd Bergmann <arnd@kernel.org> [220629 20:38]:
> omap1
> 
> common-clk and multiplatform support just landed. There are three boards
> that are likely to be in use (ams-delta, osk and nokia770) and two boards
> supported by qemu (sx1 and palmte), so we may want to keep those and
> try to eventually convert them to DT. The rest can probably get retired.

Sounds good to me. It's best to put the effort where there is some
activity. If somebody cares about other board files, please step up :)

> davinci
> 
> DT conversion has stalled, and there are 12 remaining board files,
> mostly for evaluation machines. No idea if any are still in use.

Since we already have arch/arm/boot/dts/da850* supported, removing the
remaining board files sounds good to me. Again, if somebody cares to
step up please respond :)

Regards,

Tony

Re: Scheduling (unused) board file removal for linux-6.x

[Tony Lindgren]

Hi,

* Arnd Bergmann <arnd@kernel.org> [220629 20:38]:
> omap1
> 
> common-clk and multiplatform support just landed. There are three boards
> that are likely to be in use (ams-delta, osk and nokia770) and two boards
> supported by qemu (sx1 and palmte), so we may want to keep those and
> try to eventually convert them to DT. The rest can probably get retired.

Sounds good to me. It's best to put the effort where there is some
activity. If somebody cares about other board files, please step up :)

> davinci
> 
> DT conversion has stalled, and there are 12 remaining board files,
> mostly for evaluation machines. No idea if any are still in use.

Since we already have arch/arm/boot/dts/da850* supported, removing the
remaining board files sounds good to me. Again, if somebody cares to
step up please respond :)

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 29/06/2022 22:42, Arnd Bergmann wrote:
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
> 
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
> 
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
> 
> s3c24xx
> 
> These are all scheduled for removal in early 2023 already, once the next
> longterm stable kernel is out. No changes here, but it seems useful
> to use the same timeline for removing unused board files of the other
> platforms together.
> 
> s3c64xx
> 
> There are ten board files, which are currently scheduled for removal in
> 2024, along with the DT based boards for this SoC. We can still decide
> to throw out some of the board files earlier though, while keeping the
> platform around.

I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
few boards before platform won't give us huge benefits... and anyway
just 1 and 2 years and they all will be gone.

Best regards,
Krzysztof

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 29/06/2022 22:42, Arnd Bergmann wrote:
> With the multiplatform work completed in the past merge window, and the
> scheduled deprecation of the Samsung s3c platforms, I decided to have a
> look at the remaining board files. There are 196 remaining boards, down
> from 489 boards ten years ago, but my estimate is that only few of those
> ever booted a linux-5.x kernel, and even less for future kernels. The
> question is how to find out which ones are still used, and which ones
> can go.
> 
> I would propose that we start by changing the assumption that all boards
> might be used, instead assuming that they are all outdated unless someone
> says that they actually prefer to keep it in the kernel.  I have started
> a list of all 196 boards and annotated the ones that look like candidates
> for removal [1]. If a board you use is on that list, please either reply
> here or add a comment in the document.
> 
> Unless someone has a better idea for how to proceed, I would allow
> six months for users to speak up and then remove the orphaned board
> files for the release following the LTS kernel. I can't list all boards
> individually, so here is a breakdown by platform:
> 
> s3c24xx
> 
> These are all scheduled for removal in early 2023 already, once the next
> longterm stable kernel is out. No changes here, but it seems useful
> to use the same timeline for removing unused board files of the other
> platforms together.
> 
> s3c64xx
> 
> There are ten board files, which are currently scheduled for removal in
> 2024, along with the DT based boards for this SoC. We can still decide
> to throw out some of the board files earlier though, while keeping the
> platform around.

I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
few boards before platform won't give us huge benefits... and anyway
just 1 and 2 years and they all will be gone.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Wed, Jun 29, 2022 at 10:59 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Wed, 2022-06-29 at 22:42 +0200, Arnd Bergmann wrote:
> > ep93xx
> >
> > These are still used, and the platform includes the only remaining two
> > board files that were added after linux-3.0. DT support is probably
> > doable now that common-clk works. Need information about which boards
> > are important.
>
> I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).

Noted, thanks! We'll leave them in for 2023 then.

Any thoughts on long-term uses for the platform? Do you know of users
of any products other than the reference boards that would justify doing
a DT conversion, or do we just delete the platform another time?

        Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Wed, Jun 29, 2022 at 10:59 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Wed, 2022-06-29 at 22:42 +0200, Arnd Bergmann wrote:
> > ep93xx
> >
> > These are still used, and the platform includes the only remaining two
> > board files that were added after linux-3.0. DT support is probably
> > doable now that common-clk works. Need information about which boards
> > are important.
>
> I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).

Noted, thanks! We'll leave them in for 2023 then.

Any thoughts on long-term uses for the platform? Do you know of users
of any products other than the reference boards that would justify doing
a DT conversion, or do we just delete the platform another time?

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 12:53 AM Rob Herring <robh@kernel.org> wrote:
> On Wed, Jun 29, 2022 at 2:44 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > pxa
> >
> > There are a ton of boards on this one, including seven with qemu support,
> > but based on IRC discussions, my feeling is that everyone who worked on
> > this has already lost interest a few years ago. There is rudimentary DT
> > support, so it may be helpful to pick one or two boards (gumstix?) with
> > good qemu support and keep them around for conversion to DT, while
> > removing all other boards.
>
> FWIW, u-boot is removing all PXA support.

I had a look at what boards are left in u-boot at the moment and found 41
board numbers for machines that can still boot (older) kernels using ATAG.
Almost all of them require DT in the mainline kernel already though, the
only two exceptions are:

* pxa270-colibri (getting removed from u-boot now), and
* davinci da850evm (kernel has both DT and a board file)

All other SoCs on my list already have no u-boot support at all.
For davinci, u-boot supports the same three boards as the kernel
using DT, on PXA the colibri has been the last one standing for a
while now.

       Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 12:53 AM Rob Herring <robh@kernel.org> wrote:
> On Wed, Jun 29, 2022 at 2:44 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > pxa
> >
> > There are a ton of boards on this one, including seven with qemu support,
> > but based on IRC discussions, my feeling is that everyone who worked on
> > this has already lost interest a few years ago. There is rudimentary DT
> > support, so it may be helpful to pick one or two boards (gumstix?) with
> > good qemu support and keep them around for conversion to DT, while
> > removing all other boards.
>
> FWIW, u-boot is removing all PXA support.

I had a look at what boards are left in u-boot at the moment and found 41
board numbers for machines that can still boot (older) kernels using ATAG.
Almost all of them require DT in the mainline kernel already though, the
only two exceptions are:

* pxa270-colibri (getting removed from u-boot now), and
* davinci da850evm (kernel has both DT and a board file)

All other SoCs on my list already have no u-boot support at all.
For davinci, u-boot supports the same three boards as the kernel
using DT, on PXA the colibri has been the last one standing for a
while now.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 29/06/2022 22:42, Arnd Bergmann wrote:
> >
> > s3c64xx
> >
> > There are ten board files, which are currently scheduled for removal in
> > 2024, along with the DT based boards for this SoC. We can still decide
> > to throw out some of the board files earlier though, while keeping the
> > platform around.
>
> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
> few boards before platform won't give us huge benefits... and anyway
> just 1 and 2 years and they all will be gone.

I think there is benefit in throwing out some unused s3c64xx boards
even earlier, as this would simplify some treewide cleanups that have to
touch every board file, and potentially let us drop some peripheral
device drivers that have no other users and no DT probing.

Ten boards is of course not a lot, but it's still about a third of the
board files I have currently marked as sticking around past early
2023.

        Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 29/06/2022 22:42, Arnd Bergmann wrote:
> >
> > s3c64xx
> >
> > There are ten board files, which are currently scheduled for removal in
> > 2024, along with the DT based boards for this SoC. We can still decide
> > to throw out some of the board files earlier though, while keeping the
> > platform around.
>
> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
> few boards before platform won't give us huge benefits... and anyway
> just 1 and 2 years and they all will be gone.

I think there is benefit in throwing out some unused s3c64xx boards
even earlier, as this would simplify some treewide cleanups that have to
touch every board file, and potentially let us drop some peripheral
device drivers that have no other users and no DT probing.

Ten boards is of course not a lot, but it's still about a third of the
board files I have currently marked as sticking around past early
2023.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 30/06/2022 11:08, Arnd Bergmann wrote:
> On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 29/06/2022 22:42, Arnd Bergmann wrote:
>>>
>>> s3c64xx
>>>
>>> There are ten board files, which are currently scheduled for removal in
>>> 2024, along with the DT based boards for this SoC. We can still decide
>>> to throw out some of the board files earlier though, while keeping the
>>> platform around.
>>
>> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
>> few boards before platform won't give us huge benefits... and anyway
>> just 1 and 2 years and they all will be gone.
> 
> I think there is benefit in throwing out some unused s3c64xx boards
> even earlier, as this would simplify some treewide cleanups that have to
> touch every board file, and potentially let us drop some peripheral
> device drivers that have no other users and no DT probing.
> 
> Ten boards is of course not a lot, but it's still about a third of the
> board files I have currently marked as sticking around past early
> 2023.

OK, if you have some idea which one could be the candidates.
Unfortunately I cannot provide here inputs - I have no clue which of S3C
boards have users.

Best regards,
Krzysztof

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 30/06/2022 11:08, Arnd Bergmann wrote:
> On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 29/06/2022 22:42, Arnd Bergmann wrote:
>>>
>>> s3c64xx
>>>
>>> There are ten board files, which are currently scheduled for removal in
>>> 2024, along with the DT based boards for this SoC. We can still decide
>>> to throw out some of the board files earlier though, while keeping the
>>> platform around.
>>
>> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
>> few boards before platform won't give us huge benefits... and anyway
>> just 1 and 2 years and they all will be gone.
> 
> I think there is benefit in throwing out some unused s3c64xx boards
> even earlier, as this would simplify some treewide cleanups that have to
> touch every board file, and potentially let us drop some peripheral
> device drivers that have no other users and no DT probing.
> 
> Ten boards is of course not a lot, but it's still about a third of the
> board files I have currently marked as sticking around past early
> 2023.

OK, if you have some idea which one could be the candidates.
Unfortunately I cannot provide here inputs - I have no clue which of S3C
boards have users.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Hałasa]

Hi Arnd,

> cns3xxx
>
> There is only one reference board here, the actual products that were
> previously supported, none of the board files from openwrt (now gone) made
> it in, and the DT support was never completed, so the entire platform can
> go away. We could also consider dropping the other arm11mpcore platforms
> (oxnas and the mpcore variants of realview/integrator) at the same time,
> since there are known issues with the CPU core.

I still have multiple CNS3xxx dual core boards (Gateworks Laguna) but
TBH I haven't used them for 3 years. They are fine boards, sure, but
I guess their time has long passed.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Hałasa]

Hi Arnd,

> cns3xxx
>
> There is only one reference board here, the actual products that were
> previously supported, none of the board files from openwrt (now gone) made
> it in, and the DT support was never completed, so the entire platform can
> go away. We could also consider dropping the other arm11mpcore platforms
> (oxnas and the mpcore variants of realview/integrator) at the same time,
> since there are known issues with the CPU core.

I still have multiple CNS3xxx dual core boards (Gateworks Laguna) but
TBH I haven't used them for 3 years. They are fine boards, sure, but
I guess their time has long passed.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Linus Walleij]

Hi Arnd,

thanks for looking into this!

On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:

> pxa

This looks like something that would be interesting to pick up and maintain
with DT support, if and only if there are devices with enough memory.

However I doubt there is interest.

I think the palmtops/PDAs are a bit outdated as enthusiast/hobbyist platforms
with screens because those people will use PostmarketOS with
cheap old tablets and phones these days.

> sa1100
>
> Similar to PXA, work on this appears to have stopped. Russell probably
> still has an Assabet or some other machine, but I don't know if he
> still plans to keep using new kernels on those. The only machine with
> qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
> then this should be kept as well. Probably no point doing a DT conversion
> here though.

My interest is to have something to test that CPU_SA1100 is working
on and I've been using the HP3600.

If I wanna keep doing that I should bite the bullet and convert it to
DT and multiplatform like I did with everything else I need for testing.
Else I deserve to have it removed on me and I can resurrect it
using DT if I want.

> footbridge
>
> Three machines, most notably the NetWinder that a few people still have.
> I assume Russell wants to keep the machines working that he still has.
> ep93xx
>
> These are still used, and the platform includes the only remaining two
> board files that were added after linux-3.0. DT support is probably
> doable now that common-clk works. Need information about which boards
> are important.

I'm using the NetWinder to test that CPU_SA110 is still working.

Same thing: if it matters enough to me I should convert it to DT
and multiplatform.

Someone said (ha ha only serious) to convert it to ACPI if it should
live on since it is a desktop machine...

> davinci
>
> DT conversion has stalled, and there are 12 remaining board files,
> mostly for evaluation machines. No idea if any are still in use.

TI is semi-actively maintaining DaVinci, I wonder if we can send
the message that this needs to be converted to DT pronto to live
on?

Paging Aswath @TI, who just a few days ago sent some
suspend/resume patches for GPIO:
https://lore.kernel.org/linux-gpio/20220613054310.21186-1-a-govindraju@ti.com/

Aswath: can you perhaps raise this internally at TI? Thanks!

Patches also came from Nokia (!) last year see
ea4ab99cb58cc9f8d64c0961ff9a059825f304cf

Yours,
Linus Walleij

Re: Scheduling (unused) board file removal for linux-6.x

[Linus Walleij]

Hi Arnd,

thanks for looking into this!

On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:

> pxa

This looks like something that would be interesting to pick up and maintain
with DT support, if and only if there are devices with enough memory.

However I doubt there is interest.

I think the palmtops/PDAs are a bit outdated as enthusiast/hobbyist platforms
with screens because those people will use PostmarketOS with
cheap old tablets and phones these days.

> sa1100
>
> Similar to PXA, work on this appears to have stopped. Russell probably
> still has an Assabet or some other machine, but I don't know if he
> still plans to keep using new kernels on those. The only machine with
> qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
> then this should be kept as well. Probably no point doing a DT conversion
> here though.

My interest is to have something to test that CPU_SA1100 is working
on and I've been using the HP3600.

If I wanna keep doing that I should bite the bullet and convert it to
DT and multiplatform like I did with everything else I need for testing.
Else I deserve to have it removed on me and I can resurrect it
using DT if I want.

> footbridge
>
> Three machines, most notably the NetWinder that a few people still have.
> I assume Russell wants to keep the machines working that he still has.
> ep93xx
>
> These are still used, and the platform includes the only remaining two
> board files that were added after linux-3.0. DT support is probably
> doable now that common-clk works. Need information about which boards
> are important.

I'm using the NetWinder to test that CPU_SA110 is still working.

Same thing: if it matters enough to me I should convert it to DT
and multiplatform.

Someone said (ha ha only serious) to convert it to ACPI if it should
live on since it is a desktop machine...

> davinci
>
> DT conversion has stalled, and there are 12 remaining board files,
> mostly for evaluation machines. No idea if any are still in use.

TI is semi-actively maintaining DaVinci, I wonder if we can send
the message that this needs to be converted to DT pronto to live
on?

Paging Aswath @TI, who just a few days ago sent some
suspend/resume patches for GPIO:
https://lore.kernel.org/linux-gpio/20220613054310.21186-1-a-govindraju@ti.com/

Aswath: can you perhaps raise this internally at TI? Thanks!

Patches also came from Nokia (!) last year see
ea4ab99cb58cc9f8d64c0961ff9a059825f304cf

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 11:22 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 30/06/2022 11:08, Arnd Bergmann wrote:
> > On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 29/06/2022 22:42, Arnd Bergmann wrote:
> >>>
> >>> s3c64xx
> >>>
> >>> There are ten board files, which are currently scheduled for removal in
> >>> 2024, along with the DT based boards for this SoC. We can still decide
> >>> to throw out some of the board files earlier though, while keeping the
> >>> platform around.
> >>
> >> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
> >> few boards before platform won't give us huge benefits... and anyway
> >> just 1 and 2 years and they all will be gone.
> >
> > I think there is benefit in throwing out some unused s3c64xx boards
> > even earlier, as this would simplify some treewide cleanups that have to
> > touch every board file, and potentially let us drop some peripheral
> > device drivers that have no other users and no DT probing.
> >
> > Ten boards is of course not a lot, but it's still about a third of the
> > board files I have currently marked as sticking around past early
> > 2023.
>
> OK, if you have some idea which one could be the candidates.
> Unfortunately I cannot provide here inputs - I have no clue which of S3C
> boards have users.

The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
has pointed this one out as being used as the testbed for Wolfson/Cirrus
audio codecs. The machine is also the only one that shows being worked
on from the git history. The last patches I found that look like they were
boot tested on other machines include work by Kukjin Kim in 2015 and by
Sergio Prado in 2016, but I don't see which boards they were using, and
I don't think they still care. Thomasz Figa had access to multiple
machines back in 2014, but he converted those to use DT.

If we follow the same approach that I'm suggesting for the other
platforms and nobody else speaks up, that would leave only the DT
boards plus the Cragganmore.

       Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 11:22 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 30/06/2022 11:08, Arnd Bergmann wrote:
> > On Thu, Jun 30, 2022 at 9:10 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 29/06/2022 22:42, Arnd Bergmann wrote:
> >>>
> >>> s3c64xx
> >>>
> >>> There are ten board files, which are currently scheduled for removal in
> >>> 2024, along with the DT based boards for this SoC. We can still decide
> >>> to throw out some of the board files earlier though, while keeping the
> >>> platform around.
> >>
> >> I would keep all s3c24xx/s3c64xx boards till the platform drop. Removing
> >> few boards before platform won't give us huge benefits... and anyway
> >> just 1 and 2 years and they all will be gone.
> >
> > I think there is benefit in throwing out some unused s3c64xx boards
> > even earlier, as this would simplify some treewide cleanups that have to
> > touch every board file, and potentially let us drop some peripheral
> > device drivers that have no other users and no DT probing.
> >
> > Ten boards is of course not a lot, but it's still about a third of the
> > board files I have currently marked as sticking around past early
> > 2023.
>
> OK, if you have some idea which one could be the candidates.
> Unfortunately I cannot provide here inputs - I have no clue which of S3C
> boards have users.

The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
has pointed this one out as being used as the testbed for Wolfson/Cirrus
audio codecs. The machine is also the only one that shows being worked
on from the git history. The last patches I found that look like they were
boot tested on other machines include work by Kukjin Kim in 2015 and by
Sergio Prado in 2016, but I don't see which boards they were using, and
I don't think they still care. Thomasz Figa had access to multiple
machines back in 2014, but he converted those to use DT.

If we follow the same approach that I'm suggesting for the other
platforms and nobody else speaks up, that would leave only the DT
boards plus the Cragganmore.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 30/06/2022 14:10, Arnd Bergmann wrote:

>>
>> OK, if you have some idea which one could be the candidates.
>> Unfortunately I cannot provide here inputs - I have no clue which of S3C
>> boards have users.
> 
> The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
> has pointed this one out as being used as the testbed for Wolfson/Cirrus
> audio codecs. The machine is also the only one that shows being worked
> on from the git history. The last patches I found that look like they were
> boot tested on other machines include work by Kukjin Kim in 2015 and by
> Sergio Prado in 2016, but I don't see which boards they were using, and
> I don't think they still care. Thomasz Figa had access to multiple
> machines back in 2014, but he converted those to use DT.
> 
> If we follow the same approach that I'm suggesting for the other
> platforms and nobody else speaks up, that would leave only the DT
> boards plus the Cragganmore.

Huhu, that would be nice spring cleaning! Sure, let's go with board
removal except mentioned Mark's one.


Best regards,
Krzysztof

Re: Scheduling (unused) board file removal for linux-6.x

[Krzysztof Kozlowski]

On 30/06/2022 14:10, Arnd Bergmann wrote:

>>
>> OK, if you have some idea which one could be the candidates.
>> Unfortunately I cannot provide here inputs - I have no clue which of S3C
>> boards have users.
> 
> The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
> has pointed this one out as being used as the testbed for Wolfson/Cirrus
> audio codecs. The machine is also the only one that shows being worked
> on from the git history. The last patches I found that look like they were
> boot tested on other machines include work by Kukjin Kim in 2015 and by
> Sergio Prado in 2016, but I don't see which boards they were using, and
> I don't think they still care. Thomasz Figa had access to multiple
> machines back in 2014, but he converted those to use DT.
> 
> If we follow the same approach that I'm suggesting for the other
> platforms and nobody else speaks up, that would leave only the DT
> boards plus the Cragganmore.

Huhu, that would be nice spring cleaning! Sure, let's go with board
removal except mentioned Mark's one.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Tomasz Figa]

On Fri, Jul 1, 2022 at 2:01 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/06/2022 14:10, Arnd Bergmann wrote:
>
> >>
> >> OK, if you have some idea which one could be the candidates.
> >> Unfortunately I cannot provide here inputs - I have no clue which of S3C
> >> boards have users.
> >
> > The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
> > has pointed this one out as being used as the testbed for Wolfson/Cirrus
> > audio codecs. The machine is also the only one that shows being worked
> > on from the git history. The last patches I found that look like they were
> > boot tested on other machines include work by Kukjin Kim in 2015 and by
> > Sergio Prado in 2016, but I don't see which boards they were using, and
> > I don't think they still care. Thomasz Figa had access to multiple
> > machines back in 2014, but he converted those to use DT.
> >
> > If we follow the same approach that I'm suggesting for the other
> > platforms and nobody else speaks up, that would leave only the DT
> > boards plus the Cragganmore.
>
> Huhu, that would be nice spring cleaning! Sure, let's go with board
> removal except mentioned Mark's one.

Sadly I don't have any boards alive anymore. I'm fine with any
removals you suggested. :)

Best regards,
Tomasz

Re: Scheduling (unused) board file removal for linux-6.x

[Tomasz Figa]

On Fri, Jul 1, 2022 at 2:01 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/06/2022 14:10, Arnd Bergmann wrote:
>
> >>
> >> OK, if you have some idea which one could be the candidates.
> >> Unfortunately I cannot provide here inputs - I have no clue which of S3C
> >> boards have users.
> >
> > The only one I know of is MACH_WLF_CRAGG_6410, as Mark Brown
> > has pointed this one out as being used as the testbed for Wolfson/Cirrus
> > audio codecs. The machine is also the only one that shows being worked
> > on from the git history. The last patches I found that look like they were
> > boot tested on other machines include work by Kukjin Kim in 2015 and by
> > Sergio Prado in 2016, but I don't see which boards they were using, and
> > I don't think they still care. Thomasz Figa had access to multiple
> > machines back in 2014, but he converted those to use DT.
> >
> > If we follow the same approach that I'm suggesting for the other
> > platforms and nobody else speaks up, that would leave only the DT
> > boards plus the Cragganmore.
>
> Huhu, that would be nice spring cleaning! Sure, let's go with board
> removal except mentioned Mark's one.

Sadly I don't have any boards alive anymore. I'm fine with any
removals you suggested. :)

Best regards,
Tomasz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Daniel Mack]

On 6/30/22 13:32, Linus Walleij wrote:
> This looks like something that would be interesting to pick up and maintain
> with DT support, if and only if there are devices with enough memory.
> 
> However I doubt there is interest.
> 
> I think the palmtops/PDAs are a bit outdated as enthusiast/hobbyist platforms
> with screens because those people will use PostmarketOS with
> cheap old tablets and phones these days.

It should be totally possible to port the remaining board-file powered
PXA boards over to DT. Some drivers will need DT amendments, and some
board files apply some rather exotic approaches, but with access to such
hardware, they can certainly be made work again.

I would be in favor of removing the board files, and help enthusiasts in
their efforts to to the switch to DT. In fact I would feel better to
bring back support with actual hardware testing than blindly patching
things.


Thanks,
Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Daniel Mack]

On 6/30/22 13:32, Linus Walleij wrote:
> This looks like something that would be interesting to pick up and maintain
> with DT support, if and only if there are devices with enough memory.
> 
> However I doubt there is interest.
> 
> I think the palmtops/PDAs are a bit outdated as enthusiast/hobbyist platforms
> with screens because those people will use PostmarketOS with
> cheap old tablets and phones these days.

It should be totally possible to port the remaining board-file powered
PXA boards over to DT. Some drivers will need DT amendments, and some
board files apply some rather exotic approaches, but with access to such
hardware, they can certainly be made work again.

I would be in favor of removing the board files, and help enthusiasts in
their efforts to to the switch to DT. In fact I would feel better to
bring back support with actual hardware testing than blindly patching
things.


Thanks,
Daniel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > sa1100
> >
> > Similar to PXA, work on this appears to have stopped. Russell probably
> > still has an Assabet or some other machine, but I don't know if he
> > still plans to keep using new kernels on those. The only machine with
> > qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
> > then this should be kept as well. Probably no point doing a DT conversion
> > here though.
>
> My interest is to have something to test that CPU_SA1100 is working
> on and I've been using the HP3600.

Ok. I have a H3600 and a Collie (with 64MB) here myself, though I
have no plans to do anything with these. I've marked the assabet,
h3600 and collie for staying around now.

> If I wanna keep doing that I should bite the bullet and convert it to
> DT and multiplatform like I did with everything else I need for testing.
> Else I deserve to have it removed on me and I can resurrect it
> using DT if I want.

My feeling is that it's not worth going there for any of the three
StrongARM platforms: rpc has a deadline in a few years when the
compiler stops working, and sa1100 machines are mostly limited
to 32MB (sometimes 64MB).

footbridge is probably the easiest out of the lot. I can resend
my patch to remove ebsa285 add-in mode, and I also have
some patches for cleaning up the ISA DMA.

> > davinci
> >
> > DT conversion has stalled, and there are 12 remaining board files,
> > mostly for evaluation machines. No idea if any are still in use.
>
> TI is semi-actively maintaining DaVinci, I wonder if we can send
> the message that this needs to be converted to DT pronto to live
> on?

I assume Sekhar and Bartosz have a plan. As Tony said, the
important machines are the DA850 ones that are already converted.

> Paging Aswath @TI, who just a few days ago sent some
> suspend/resume patches for GPIO:
> https://lore.kernel.org/linux-gpio/20220613054310.21186-1-a-govindraju@ti.com/
>
> Aswath: can you perhaps raise this internally at TI? Thanks!
>
> Patches also came from Nokia (!) last year see
> ea4ab99cb58cc9f8d64c0961ff9a059825f304cf

I would assume that both have been for keystone2 or k3, which
share a lot of the drivers with davinci and are widely used with DT.

        Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > sa1100
> >
> > Similar to PXA, work on this appears to have stopped. Russell probably
> > still has an Assabet or some other machine, but I don't know if he
> > still plans to keep using new kernels on those. The only machine with
> > qemu support is Collie (Sharp SL-5500), so if we keep any boards at all,
> > then this should be kept as well. Probably no point doing a DT conversion
> > here though.
>
> My interest is to have something to test that CPU_SA1100 is working
> on and I've been using the HP3600.

Ok. I have a H3600 and a Collie (with 64MB) here myself, though I
have no plans to do anything with these. I've marked the assabet,
h3600 and collie for staying around now.

> If I wanna keep doing that I should bite the bullet and convert it to
> DT and multiplatform like I did with everything else I need for testing.
> Else I deserve to have it removed on me and I can resurrect it
> using DT if I want.

My feeling is that it's not worth going there for any of the three
StrongARM platforms: rpc has a deadline in a few years when the
compiler stops working, and sa1100 machines are mostly limited
to 32MB (sometimes 64MB).

footbridge is probably the easiest out of the lot. I can resend
my patch to remove ebsa285 add-in mode, and I also have
some patches for cleaning up the ISA DMA.

> > davinci
> >
> > DT conversion has stalled, and there are 12 remaining board files,
> > mostly for evaluation machines. No idea if any are still in use.
>
> TI is semi-actively maintaining DaVinci, I wonder if we can send
> the message that this needs to be converted to DT pronto to live
> on?

I assume Sekhar and Bartosz have a plan. As Tony said, the
important machines are the DA850 ones that are already converted.

> Paging Aswath @TI, who just a few days ago sent some
> suspend/resume patches for GPIO:
> https://lore.kernel.org/linux-gpio/20220613054310.21186-1-a-govindraju@ti.com/
>
> Aswath: can you perhaps raise this internally at TI? Thanks!
>
> Patches also came from Nokia (!) last year see
> ea4ab99cb58cc9f8d64c0961ff9a059825f304cf

I would assume that both have been for keystone2 or k3, which
share a lot of the drivers with davinci and are widely used with DT.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hi!

On Fri, 2022-07-01 at 12:53 +0200, Arnd Bergmann wrote:
> > Patches also came from Nokia (!) last year see
> > ea4ab99cb58cc9f8d64c0961ff9a059825f304cf
> 
> I would assume that both have been for keystone2 or k3, which
> share a lot of the drivers with davinci and are widely used with DT.

Indeed, this is for Keystone 2.

-- 
Alexander Sverdlin.

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hi!

On Fri, 2022-07-01 at 12:53 +0200, Arnd Bergmann wrote:
> > Patches also came from Nokia (!) last year see
> > ea4ab99cb58cc9f8d64c0961ff9a059825f304cf
> 
> I would assume that both have been for keystone2 or k3, which
> share a lot of the drivers with davinci and are widely used with DT.

Indeed, this is for Keystone 2.

-- 
Alexander Sverdlin.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Linus Walleij]

On Fri, Jul 1, 2022 at 12:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
> On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:

> > > davinci
> > >
> > > DT conversion has stalled, and there are 12 remaining board files,
> > > mostly for evaluation machines. No idea if any are still in use.
> >
> > TI is semi-actively maintaining DaVinci, I wonder if we can send
> > the message that this needs to be converted to DT pronto to live
> > on?
>
> I assume Sekhar and Bartosz have a plan. As Tony said, the
> important machines are the DA850 ones that are already converted.

TI is OK with having these removed, my gpiod-conversion patches
has been resent a few merge windows without getting merged or
tested. I will send patches to simply delete them,
then the hobbyists can take it from there if they don't like it.

Yours,
Linus Walleij

Re: Scheduling (unused) board file removal for linux-6.x

[Linus Walleij]

On Fri, Jul 1, 2022 at 12:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
> On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:

> > > davinci
> > >
> > > DT conversion has stalled, and there are 12 remaining board files,
> > > mostly for evaluation machines. No idea if any are still in use.
> >
> > TI is semi-actively maintaining DaVinci, I wonder if we can send
> > the message that this needs to be converted to DT pronto to live
> > on?
>
> I assume Sekhar and Bartosz have a plan. As Tony said, the
> important machines are the DA850 ones that are already converted.

TI is OK with having these removed, my gpiod-conversion patches
has been resent a few merge windows without getting merged or
tested. I will send patches to simply delete them,
then the hobbyists can take it from there if they don't like it.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Fri, Jul 1, 2022 at 1:43 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jul 1, 2022 at 12:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > davinci
> > > >
> > > > DT conversion has stalled, and there are 12 remaining board files,
> > > > mostly for evaluation machines. No idea if any are still in use.
> > >
> > > TI is semi-actively maintaining DaVinci, I wonder if we can send
> > > the message that this needs to be converted to DT pronto to live
> > > on?
> >
> > I assume Sekhar and Bartosz have a plan. As Tony said, the
> > important machines are the DA850 ones that are already converted.
>
> TI is OK with having these removed, my gpiod-conversion patches
> has been resent a few merge windows without getting merged or
> tested. I will send patches to simply delete them,
> then the hobbyists can take it from there if they don't like it.

Fine with me. While my plan was to give all users six months
time to speak up across all platforms, but if a platform maintainer
wants to speed up removing their boards, I'm not complaining.

       Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Fri, Jul 1, 2022 at 1:43 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jul 1, 2022 at 12:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Thu, Jun 30, 2022 at 1:32 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Wed, Jun 29, 2022 at 10:43 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > davinci
> > > >
> > > > DT conversion has stalled, and there are 12 remaining board files,
> > > > mostly for evaluation machines. No idea if any are still in use.
> > >
> > > TI is semi-actively maintaining DaVinci, I wonder if we can send
> > > the message that this needs to be converted to DT pronto to live
> > > on?
> >
> > I assume Sekhar and Bartosz have a plan. As Tony said, the
> > important machines are the DA850 ones that are already converted.
>
> TI is OK with having these removed, my gpiod-conversion patches
> has been resent a few merge windows without getting merged or
> tested. I will send patches to simply delete them,
> then the hobbyists can take it from there if they don't like it.

Fine with me. While my plan was to give all users six months
time to speak up across all platforms, but if a platform maintainer
wants to speed up removing their boards, I'm not complaining.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Christoph Hellwig]

On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> footbridge is probably the easiest out of the lot. I can resend
> my patch to remove ebsa285 add-in mode, and I also have
> some patches for cleaning up the ISA DMA.

Given that no one could be bothered to test the DMA mapping patches
on footbridge so far I wonder if it isn't actually dead yet..

Re: Scheduling (unused) board file removal for linux-6.x

[Christoph Hellwig]

On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> footbridge is probably the easiest out of the lot. I can resend
> my patch to remove ebsa285 add-in mode, and I also have
> some patches for cleaning up the ISA DMA.

Given that no one could be bothered to test the DMA mapping patches
on footbridge so far I wonder if it isn't actually dead yet..

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Sat, Jul 2, 2022 at 11:47 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> > footbridge is probably the easiest out of the lot. I can resend
> > my patch to remove ebsa285 add-in mode, and I also have
> > some patches for cleaning up the ISA DMA.
>
> Given that no one could be bothered to test the DMA mapping patches
> on footbridge so far I wonder if it isn't actually dead yet..

IIRC Marc Zyngier tested your patches successfully on the NetWinder, which
is a footbridge machine. It's Russell's SA1100/Assabet that has not been
tested.

        Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Sat, Jul 2, 2022 at 11:47 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> > footbridge is probably the easiest out of the lot. I can resend
> > my patch to remove ebsa285 add-in mode, and I also have
> > some patches for cleaning up the ISA DMA.
>
> Given that no one could be bothered to test the DMA mapping patches
> on footbridge so far I wonder if it isn't actually dead yet..

IIRC Marc Zyngier tested your patches successfully on the NetWinder, which
is a footbridge machine. It's Russell's SA1100/Assabet that has not been
tested.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Christoph Hellwig]

On Sat, Jul 02, 2022 at 12:06:02PM +0200, Arnd Bergmann wrote:
> > On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> > > footbridge is probably the easiest out of the lot. I can resend
> > > my patch to remove ebsa285 add-in mode, and I also have
> > > some patches for cleaning up the ISA DMA.
> >
> > Given that no one could be bothered to test the DMA mapping patches
> > on footbridge so far I wonder if it isn't actually dead yet..
> 
> IIRC Marc Zyngier tested your patches successfully on the NetWinder, which
> is a footbridge machine. It's Russell's SA1100/Assabet that has not been
> tested.

Now that I look back that seems to be the case. In that case the same
applies to assabet :)

Re: Scheduling (unused) board file removal for linux-6.x

[Christoph Hellwig]

On Sat, Jul 02, 2022 at 12:06:02PM +0200, Arnd Bergmann wrote:
> > On Fri, Jul 01, 2022 at 12:53:46PM +0200, Arnd Bergmann wrote:
> > > footbridge is probably the easiest out of the lot. I can resend
> > > my patch to remove ebsa285 add-in mode, and I also have
> > > some patches for cleaning up the ISA DMA.
> >
> > Given that no one could be bothered to test the DMA mapping patches
> > on footbridge so far I wonder if it isn't actually dead yet..
> 
> IIRC Marc Zyngier tested your patches successfully on the NetWinder, which
> is a footbridge machine. It's Russell's SA1100/Assabet that has not been
> tested.

Now that I look back that seems to be the case. In that case the same
applies to assabet :)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hello Nikita, Lukasz, Hartley,

On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:
> > > ep93xx
> > > 
> > > These are still used, and the platform includes the only remaining two
> > > board files that were added after linux-3.0. DT support is probably
> > > doable now that common-clk works. Need information about which boards
> > > are important.
> > 
> > I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).
> 
> Noted, thanks! We'll leave them in for 2023 then.
> 
> Any thoughts on long-term uses for the platform? Do you know of users
> of any products other than the reference boards that would justify doing
> a DT conversion, or do we just delete the platform another time?

what are your projections for EP93xx support?

I'm personally a bit pessimistic about DT conversion because existing partition
tables were already challenged by the kernel growth. It has at least grown
+60% with the same config since 2006. This makes me think that 2023 EOL for this
SoC might be feasible.

-- 
Alexander Sverdlin.

Re: Scheduling (unused) board file removal for linux-6.x

[Alexander Sverdlin]

Hello Nikita, Lukasz, Hartley,

On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:
> > > ep93xx
> > > 
> > > These are still used, and the platform includes the only remaining two
> > > board files that were added after linux-3.0. DT support is probably
> > > doable now that common-clk works. Need information about which boards
> > > are important.
> > 
> > I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).
> 
> Noted, thanks! We'll leave them in for 2023 then.
> 
> Any thoughts on long-term uses for the platform? Do you know of users
> of any products other than the reference boards that would justify doing
> a DT conversion, or do we just delete the platform another time?

what are your projections for EP93xx support?

I'm personally a bit pessimistic about DT conversion because existing partition
tables were already challenged by the kernel growth. It has at least grown
+60% with the same config since 2006. This makes me think that 2023 EOL for this
SoC might be feasible.

-- 
Alexander Sverdlin.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Sun, Jul 3, 2022 at 1:24 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> Hello Nikita, Lukasz, Hartley,
> On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:
> > > > ep93xx
> > > >
> > > > These are still used, and the platform includes the only remaining two
> > > > board files that were added after linux-3.0. DT support is probably
> > > > doable now that common-clk works. Need information about which boards
> > > > are important.
> > >
> > > I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).
> >
> > Noted, thanks! We'll leave them in for 2023 then.
> >
> > Any thoughts on long-term uses for the platform? Do you know of users
> > of any products other than the reference boards that would justify doing
> > a DT conversion, or do we just delete the platform another time?
>
> what are your projections for EP93xx support?
>
> I'm personally a bit pessimistic about DT conversion because existing partition
> tables were already challenged by the kernel growth. It has at least grown
> +60% with the same config since 2006. This makes me think that 2023 EOL for this
> SoC might be feasible.

I don't think converting the platform to DT will make the space
problem noticeably
worse, as the DT infrastructure is already enabled unconditionally since the
multiplatform enablement. There are probably a few more lines that need to be
added to parse DT properties in a couple of drivers, but removing the
board files
will save a bit as well.

There is little hope of stopping the general accumulation of code bloat through,
so any boards that are hitting a size limit are probably at the end of
their lives
regardless.

         Arnd

Re: Scheduling (unused) board file removal for linux-6.x

[Arnd Bergmann]

On Sun, Jul 3, 2022 at 1:24 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> Hello Nikita, Lukasz, Hartley,
> On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:
> > > > ep93xx
> > > >
> > > > These are still used, and the platform includes the only remaining two
> > > > board files that were added after linux-3.0. DT support is probably
> > > > doable now that common-clk works. Need information about which boards
> > > > are important.
> > >
> > > I'm still maintaining/able to test CONFIG_MACH_EDB93XX (edb93xx.c).
> >
> > Noted, thanks! We'll leave them in for 2023 then.
> >
> > Any thoughts on long-term uses for the platform? Do you know of users
> > of any products other than the reference boards that would justify doing
> > a DT conversion, or do we just delete the platform another time?
>
> what are your projections for EP93xx support?
>
> I'm personally a bit pessimistic about DT conversion because existing partition
> tables were already challenged by the kernel growth. It has at least grown
> +60% with the same config since 2006. This makes me think that 2023 EOL for this
> SoC might be feasible.

I don't think converting the platform to DT will make the space
problem noticeably
worse, as the DT infrastructure is already enabled unconditionally since the
multiplatform enablement. There are probably a few more lines that need to be
added to parse DT properties in a couple of drivers, but removing the
board files
will save a bit as well.

There is little hope of stopping the general accumulation of code bloat through,
so any boards that are hitting a size limit are probably at the end of
their lives
regardless.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Nikita Shubin]

Hello Arnd and Alexander!

On Sun, 3 Jul 2022 18:11:36 +0200
Arnd Bergmann <arnd@kernel.org> wrote:

> On Sun, Jul 3, 2022 at 1:24 PM Alexander Sverdlin
> <alexander.sverdlin@gmail.com> wrote:
> > Hello Nikita, Lukasz, Hartley,
> > On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:  
> > > > > ep93xx
> > > > >
> > > > > These are still used, and the platform includes the only
> > > > > remaining two board files that were added after linux-3.0. DT
> > > > > support is probably doable now that common-clk works. Need
> > > > > information about which boards are important.  
> > > >
> > > > I'm still maintaining/able to test CONFIG_MACH_EDB93XX
> > > > (edb93xx.c).  
> > >
> > > Noted, thanks! We'll leave them in for 2023 then.
> > >
> > > Any thoughts on long-term uses for the platform? Do you know of
> > > users of any products other than the reference boards that would
> > > justify doing a DT conversion, or do we just delete the platform
> > > another time?  
> >
> > what are your projections for EP93xx support?
> >
> > I'm personally a bit pessimistic about DT conversion because
> > existing partition tables were already challenged by the kernel
> > growth. It has at least grown +60% with the same config since 2006.
> > This makes me think that 2023 EOL for this SoC might be feasible.  
> 
> I don't think converting the platform to DT will make the space
> problem noticeably
> worse, as the DT infrastructure is already enabled unconditionally
> since the multiplatform enablement. There are probably a few more
> lines that need to be added to parse DT properties in a couple of
> drivers, but removing the board files
> will save a bit as well.
> 
> There is little hope of stopping the general accumulation of code
> bloat through, so any boards that are hitting a size limit are
> probably at the end of their lives
> regardless.
> 
>          Arnd

On the bright side i have a working (bootable with UBIFS rootfs)
dt-based version of ts7250. Did almost a year ago, but unfortunately
got caught by RISC-V bustle, Sorry for github links:

Almost "clean" branch:
https://github.com/maquefel/linux/tree/ep93xx_dt_rework 

Dirty, last known good branch:
https://github.com/maquefel/linux/tree/gpio/devel-ep93xx-rework-v6

But all my users moved from ts7250 usage to other products, so i am
okay if it vanishes from main tree...

I have a dozen of ts7250, even with TS-DIO24, TS-SER4, CAN etc..., if
someone is interested in Device Tree version of ep93xx/ts7250, it's not
a problem for me to finalize the current work on the top of most recent
version, but i can test only on ts7250.

Yours,
Nikita Shubin.









_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Scheduling (unused) board file removal for linux-6.x

[Nikita Shubin]

Hello Arnd and Alexander!

On Sun, 3 Jul 2022 18:11:36 +0200
Arnd Bergmann <arnd@kernel.org> wrote:

> On Sun, Jul 3, 2022 at 1:24 PM Alexander Sverdlin
> <alexander.sverdlin@gmail.com> wrote:
> > Hello Nikita, Lukasz, Hartley,
> > On Thu, 2022-06-30 at 09:42 +0200, Arnd Bergmann wrote:  
> > > > > ep93xx
> > > > >
> > > > > These are still used, and the platform includes the only
> > > > > remaining two board files that were added after linux-3.0. DT
> > > > > support is probably doable now that common-clk works. Need
> > > > > information about which boards are important.  
> > > >
> > > > I'm still maintaining/able to test CONFIG_MACH_EDB93XX
> > > > (edb93xx.c).  
> > >
> > > Noted, thanks! We'll leave them in for 2023 then.
> > >
> > > Any thoughts on long-term uses for the platform? Do you know of
> > > users of any products other than the reference boards that would
> > > justify doing a DT conversion, or do we just delete the platform
> > > another time?  
> >
> > what are your projections for EP93xx support?
> >
> > I'm personally a bit pessimistic about DT conversion because
> > existing partition tables were already challenged by the kernel
> > growth. It has at least grown +60% with the same config since 2006.
> > This makes me think that 2023 EOL for this SoC might be feasible.  
> 
> I don't think converting the platform to DT will make the space
> problem noticeably
> worse, as the DT infrastructure is already enabled unconditionally
> since the multiplatform enablement. There are probably a few more
> lines that need to be added to parse DT properties in a couple of
> drivers, but removing the board files
> will save a bit as well.
> 
> There is little hope of stopping the general accumulation of code
> bloat through, so any boards that are hitting a size limit are
> probably at the end of their lives
> regardless.
> 
>          Arnd

On the bright side i have a working (bootable with UBIFS rootfs)
dt-based version of ts7250. Did almost a year ago, but unfortunately
got caught by RISC-V bustle, Sorry for github links:

Almost "clean" branch:
https://github.com/maquefel/linux/tree/ep93xx_dt_rework 

Dirty, last known good branch:
https://github.com/maquefel/linux/tree/gpio/devel-ep93xx-rework-v6

But all my users moved from ts7250 usage to other products, so i am
okay if it vanishes from main tree...

I have a dozen of ts7250, even with TS-DIO24, TS-SER4, CAN etc..., if
someone is interested in Device Tree version of ep93xx/ts7250, it's not
a problem for me to finalize the current work on the top of most recent
version, but i can test only on ts7250.

Yours,
Nikita Shubin.