[PATCH] maintainership update for the Marvell Orion family of SOCs

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Nicolas Pitre]

While Lennert and I have moved our focus to other things, some people
picked up the slack on those platforms.  Let's empower them with a more 
official status.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>

diff --git a/MAINTAINERS b/MAINTAINERS
index bb76fc42fc..348b881f74 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -908,11 +908,12 @@ ARM/MAGICIAN MACHINE SUPPORT
 M:	Philipp Zabel <philipp.zabel@gmail.com>
 S:	Maintained
 
-ARM/Marvell Loki/Kirkwood/MV78xx0/Orion SOC support
-M:	Lennert Buytenhek <kernel@wantstofly.org>
-M:	Nicolas Pitre <nico@fluxnic.net>
+ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
+M:	Jason Cooper <jason@lakedaemon.net>
+M:	Andrew Lunn <andrew@lunn.ch>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Odd Fixes
+S:	Maintained
+F:	arch/arm/mach-dove/
 F:	arch/arm/mach-kirkwood/
 F:	arch/arm/mach-mv78xx0/
 F:	arch/arm/mach-orion5x/

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Jason Cooper]

On Mon, Apr 30, 2012 at 01:44:48PM -0400, Nicolas Pitre wrote:
> While Lennert and I have moved our focus to other things, some people
> picked up the slack on those platforms.  Let's empower them with a more 
> official status.
> 
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>

Acked-by: Jason Cooper <jason@lakedaemon.net>

> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bb76fc42fc..348b881f74 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -908,11 +908,12 @@ ARM/MAGICIAN MACHINE SUPPORT
>  M:	Philipp Zabel <philipp.zabel@gmail.com>
>  S:	Maintained
>  
> -ARM/Marvell Loki/Kirkwood/MV78xx0/Orion SOC support
> -M:	Lennert Buytenhek <kernel@wantstofly.org>
> -M:	Nicolas Pitre <nico@fluxnic.net>
> +ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
> +M:	Jason Cooper <jason@lakedaemon.net>
> +M:	Andrew Lunn <andrew@lunn.ch>
>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> -S:	Odd Fixes
> +S:	Maintained
> +F:	arch/arm/mach-dove/
>  F:	arch/arm/mach-kirkwood/
>  F:	arch/arm/mach-mv78xx0/
>  F:	arch/arm/mach-orion5x/

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Monday 30 April 2012, Jason Cooper wrote:
> 
> On Mon, Apr 30, 2012 at 01:44:48PM -0400, Nicolas Pitre wrote:
> > While Lennert and I have moved our focus to other things, some people
> > picked up the slack on those platforms.  Let's empower them with a more 
> > official status.
> > 
> > Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> > Cc: Lennert Buytenhek <kernel@wantstofly.org>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> 
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> 
Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Andrew Lunn]

On Mon, Apr 30, 2012 at 06:33:52PM +0000, Arnd Bergmann wrote:
> On Monday 30 April 2012, Jason Cooper wrote:
> > 
> > On Mon, Apr 30, 2012 at 01:44:48PM -0400, Nicolas Pitre wrote:
> > > While Lennert and I have moved our focus to other things, some people
> > > picked up the slack on those platforms.  Let's empower them with a more 
> > > official status.
> > > 
> > > Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> > > Cc: Lennert Buytenhek <kernel@wantstofly.org>
> > > Cc: Jason Cooper <jason@lakedaemon.net>
> > > Cc: Andrew Lunn <andrew@lunn.ch>
> > 
> > Acked-by: Jason Cooper <jason@lakedaemon.net>
> > 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Andrew Lunn <andrew@lunn.ch>

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnaud Patard (Rtp)]

Hi,

Nicolas Pitre <nico@fluxnic.net> writes:
> While Lennert and I have moved our focus to other things, some people
> picked up the slack on those platforms.  Let's empower them with a more 
> official status.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bb76fc42fc..348b881f74 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -908,11 +908,12 @@ ARM/MAGICIAN MACHINE SUPPORT
>  M:	Philipp Zabel <philipp.zabel@gmail.com>
>  S:	Maintained
>  
> -ARM/Marvell Loki/Kirkwood/MV78xx0/Orion SOC support
> -M:	Lennert Buytenhek <kernel@wantstofly.org>
> -M:	Nicolas Pitre <nico@fluxnic.net>
> +ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
> +M:	Jason Cooper <jason@lakedaemon.net>
> +M:	Andrew Lunn <andrew@lunn.ch>
>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> -S:	Odd Fixes
> +S:	Maintained
> +F:	arch/arm/mach-dove/
>  F:	arch/arm/mach-kirkwood/
>  F:	arch/arm/mach-mv78xx0/
>  F:	arch/arm/mach-orion5x/

Sorry to hijack a little bit this thread, but I got a few days ago a
88ap510/dove device so I was wondering if the work currently done on
kirkwood would allow us the same kernel binary at least on dove and
kirkwood ? [1] If so, when it'll be possible, will it be considered to
move the corresponding board setup from
arch/arm/mach-{dove,kirkwood,...} into a new directory, like what was
done on recently on imx ?

Thanks,
Arnaud

[1] I'm only talking of kirkwood and dove because it's only what I can
test. Of course, if it can be a single kernel binary for
dove/kirkwood/mv78xx0/orion5x, it'll be even better.

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Monday 30 April 2012, Arnaud Patard wrote:
> Sorry to hijack a little bit this thread, but I got a few days ago a
> 88ap510/dove device so I was wondering if the work currently done on
> kirkwood would allow us the same kernel binary at least on dove and
> kirkwood ? [1] If so, when it'll be possible, will it be considered to
> move the corresponding board setup from
> arch/arm/mach-{dove,kirkwood,...} into a new directory, like what was
> done on recently on imx ?
> 
> [1] I'm only talking of kirkwood and dove because it's only what I can
> test. Of course, if it can be a single kernel binary for
> dove/kirkwood/mv78xx0/orion5x, it'll be even better.

While I don't know of anyone working on this currently, I've also thought
about it being doable, but I would defer it until we can probe all
the devices using the device tree, because at that point it will get
much simpler. We might just move all the DT based board support into
the plat-orion directory and leave the other directories for the classic
probing, eventually to be removed when the new stuff can handle all the
machines that someone cares about.

Note that dove is fundamentally incompatible with the others at runtime,
being ARMv7 based instead of ARMv5, but it could still live in the same
directory, like we do for other platforms.

	Arnd

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Monday 30 April 2012, Nicolas Pitre wrote:
> While Lennert and I have moved our focus to other things, some people
> picked up the slack on those platforms.  Let's empower them with a more 
> official status.
> 
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>

I've applied the patch with the Acks to the next/maintainers branch of arm-soc
now. Thanks everyone!

	Arnd

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnaud Patard (Rtp)]

Arnd Bergmann <arnd@arndb.de> writes:

> On Monday 30 April 2012, Arnaud Patard wrote:
>> Sorry to hijack a little bit this thread, but I got a few days ago a
>> 88ap510/dove device so I was wondering if the work currently done on
>> kirkwood would allow us the same kernel binary at least on dove and
>> kirkwood ? [1] If so, when it'll be possible, will it be considered to
>> move the corresponding board setup from
>> arch/arm/mach-{dove,kirkwood,...} into a new directory, like what was
>> done on recently on imx ?
>> 
>> [1] I'm only talking of kirkwood and dove because it's only what I can
>> test. Of course, if it can be a single kernel binary for
>> dove/kirkwood/mv78xx0/orion5x, it'll be even better.
>
> While I don't know of anyone working on this currently, I've also thought
> about it being doable, but I would defer it until we can probe all
> the devices using the device tree, because at that point it will get
> much simpler. We might just move all the DT based board support into

ok.

> the plat-orion directory and leave the other directories for the classic
> probing, eventually to be removed when the new stuff can handle all the
> machines that someone cares about.

I'm not sure we'll be able to remove any machine without being sure it's
working and it can take quite some time. orion/kirkwood/... are used on
NAS boxes so I guess people are not necessary updating their kernel on a
regular basis.

>
> Note that dove is fundamentally incompatible with the others at runtime,
> being ARMv7 based instead of ARMv5, but it could still live in the same
> directory, like we do for other platforms.

oh, right. I guess I need some sleep.

Arnaud

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Monday 30 April 2012, Arnaud Patard wrote:
> > the plat-orion directory and leave the other directories for the classic
> > probing, eventually to be removed when the new stuff can handle all the
> > machines that someone cares about.
> 
> I'm not sure we'll be able to remove any machine without being sure it's
> working and it can take quite some time. orion/kirkwood/... are used on
> NAS boxes so I guess people are not necessary updating their kernel on a
> regular basis.

Well, there is no reason to rush this at all, it could live in parallel
for a couple of years. But at one point we can decide that if nobody has
bothered to write the .dts file for one board and tested it that nobody
cares about that board any more and it can just get removed and possibly
added back in dts form when someone does complain.

	Arnd

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Andrew Lunn]

> Well, there is no reason to rush this at all, it could live in parallel
> for a couple of years. But at one point we can decide that if nobody has
> bothered to write the .dts file for one board and tested it that nobody
> cares about that board any more and it can just get removed and possibly
> added back in dts form when someone does complain.

Probably a FAQ, but maybe somebody can point me in the right
direction. How will Debian, Ubuntu, etc, deal with old machines who's
u-boot does not support DT, yet the kernel has moved on and only has
DT support for a board? Will the kernel install process need to
determine what board the machine is and append the DT to the end of
the kernel? Or do we envisage a process where all DT are appended to
the kernel, and the machine ID, as passed by the old uboot, is used to
pick the correct DT?

    Thanks
	Andrew

Re: [PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Tuesday 01 May 2012, Andrew Lunn wrote:
> > Well, there is no reason to rush this at all, it could live in parallel
> > for a couple of years. But at one point we can decide that if nobody has
> > bothered to write the .dts file for one board and tested it that nobody
> > cares about that board any more and it can just get removed and possibly
> > added back in dts form when someone does complain.
> 
> Probably a FAQ, but maybe somebody can point me in the right
> direction. How will Debian, Ubuntu, etc, deal with old machines who's
> u-boot does not support DT, yet the kernel has moved on and only has
> DT support for a board? Will the kernel install process need to
> determine what board the machine is and append the DT to the end of
> the kernel?

I think that is the most likely scenario. Another option would be
to provide a replacement or second-stage boot loader that actually
understands DT and that gets loaded instead of the kernel by the
first-stage boot loader.

> Or do we envisage a process where all DT are appended to
> the kernel, and the machine ID, as passed by the old uboot, is used to
> pick the correct DT?

This has been discussed in the past, but IIRC we decided against putting
that logic into the kernel. Folks on devicetree-discuss@l.o.o might remember
the details better than me.

	Arnd

[PATCH] maintainership update for the Marvell Orion family of SOCs

[Arnd Bergmann]

On Tuesday 01 May 2012, Andrew Lunn wrote:
> > Well, there is no reason to rush this at all, it could live in parallel
> > for a couple of years. But at one point we can decide that if nobody has
> > bothered to write the .dts file for one board and tested it that nobody
> > cares about that board any more and it can just get removed and possibly
> > added back in dts form when someone does complain.
> 
> Probably a FAQ, but maybe somebody can point me in the right
> direction. How will Debian, Ubuntu, etc, deal with old machines who's
> u-boot does not support DT, yet the kernel has moved on and only has
> DT support for a board? Will the kernel install process need to
> determine what board the machine is and append the DT to the end of
> the kernel?

I think that is the most likely scenario. Another option would be
to provide a replacement or second-stage boot loader that actually
understands DT and that gets loaded instead of the kernel by the
first-stage boot loader.

> Or do we envisage a process where all DT are appended to
> the kernel, and the machine ID, as passed by the old uboot, is used to
> pick the correct DT?

This has been discussed in the past, but IIRC we decided against putting
that logic into the kernel. Folks on devicetree-discuss at l.o.o might remember
the details better than me.

	Arnd