Thread (21 messages) flat view 21 messages, 5 authors, 2012-09-25

[PATCH 5/6] ARM: dove: Remove watchdog from DT

From: arnd@arndb.de (Arnd Bergmann)
Date: 2012-09-25 11:21:45
Also in: lkml

On Tuesday 25 September 2012, Andrew Lunn wrote:
On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
quoted
On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
quoted
I principle, i agree. However, i'm not too sure about mach-orion5x &
mach-mv78xx0. orion5x has probably been broken since -rc1 was released
and nobody noticed. In the same time, we got around 5 people
independently reporting kirkwood was broken. We have not received any
new boards for orion5x in the time i've been looking at Orion
platforms. mv78xx0 only has one board which is not a Marvell reference
design. So im tempted to not spend any effort moving orion5x or
mv78xx0 to DT unless these actually hinder the effort of moving the
others to DT.  What may make sense is to flatten mv78xx0 and orion5x
into plat-orion and then just watch the bit-rot happen.
I'll try to see if I can get people from LaCie to test mach-orion5x as
I have a few contacts there, and I'll contact Marvell to see if they can
still provide Orion-based platforms.
Marvell supplied my one one reference platform. So i can do some
testing that the basic infrastructure works.

But the problem with converting to DT is that there is a lot of
brainless monkey work needed per supported board, and its very easy to
make a typo. So each board converted to DT needs testing. I don't know
if we can find testers for all the boards. But should we throw out
working boards just because we cannot find somebody to test the DT
version?
We can throw them out in a staged process. I think the first step should
be ensuring that the platform support works on one (or better a few)
board reliably, and merge support for that into mach-mvebu but leave
the other ~20 board files in mach-orion5x without spending too much work
on them. Whether that means pinctrl support for mach-orion5x is a something
you need to figure out.

The next step would be to label mach-orion5x as deprecated in Kconfig for
a release and change the help text so it tells people to move to mach-mvebu
and submit dts files.

After that, we can leave mach-orion5x in the kernel for another release but
completely disable the option to enable it in Kconfig as a last warning.
This means anyone who is using it will have to move on or talk to us about
extending the transition period.

Finally, we remove mach-orion5x. Hopefully by that time, everyone who is
using it will have contributed a dts file for it.
quoted
Regarding mv78xx0, I agree that I'm not sure what to do. The number of
supported platforms is small. Should we simply mark mv78xx0 deprecated
now, wait a few release cycles to see if anyone shows up, and see what
to do at this point?
We should let Sebastien Requiem comment. He is the only person outside of
Marvell who has contributed a board file for mv78xx0. If he's interested in
keeping it alive, he's hopefully also able to find the time to test the
devicetree version of that platform in mach-mvebu. Similarly, if anyone
has the MASA reference design, that one could be moved over to mach-mvebu
first.

There is a much smaller user base for mv78xx0 than for orion5x, so as long
as we can keep the support working with DT, we can throw out the legacy
code much faster than for orion. If it doesn't get put into mach-mvebu
and you can't find anyone who has hardware to test on, you could also
stop maintaining it and leave it to bitrot, but I wouldn't just remove it
on a fast track then.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help