[PATCH] ARM: Add lsxhl machine type to mach-types

[PATCH] ARM: Add lsxhl machine type to mach-types

[Michael Walle]

(Re-)add Buffalo Linkstation Pro LS-XHL machine type.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 arch/arm/tools/mach-types |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index 5bdeef9..d50917e 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -458,6 +458,7 @@ mityomapl138		MACH_MITYOMAPL138	MITYOMAPL138		2650
 guruplug		MACH_GURUPLUG		GURUPLUG		2659
 spear310		MACH_SPEAR310		SPEAR310		2660
 spear320		MACH_SPEAR320		SPEAR320		2661
+lsxhl			MACH_LSXHL		LSXHL			2663
 aquila			MACH_AQUILA		AQUILA			2676
 sheeva_esata		MACH_ESATA_SHEEVAPLUG	ESATA_SHEEVAPLUG	2678
 msm7x30_surf		MACH_MSM7X30_SURF	MSM7X30_SURF		2679
-- 
1.7.2.5

[PATCH] ARM: Add lsxhl machine type to mach-types

[Michael Walle]

Am Montag 07 November 2011, 21:54:11 schrieb Michael Walle:
> (Re-)add Buffalo Linkstation Pro LS-XHL machine type.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  arch/arm/tools/mach-types |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
> index 5bdeef9..d50917e 100644
> --- a/arch/arm/tools/mach-types
> +++ b/arch/arm/tools/mach-types
> @@ -458,6 +458,7 @@ mityomapl138		MACH_MITYOMAPL138	
MITYOMAPL138		2650
>  guruplug		MACH_GURUPLUG		GURUPLUG		2659
>  spear310		MACH_SPEAR310		SPEAR310		2660
>  spear320		MACH_SPEAR320		SPEAR320		2661
> +lsxhl			MACH_LSXHL		LSXHL			
2663
>  aquila			MACH_AQUILA		AQUILA			
2676
>  sheeva_esata		MACH_ESATA_SHEEVAPLUG	ESATA_SHEEVAPLUG	2678
>  msm7x30_surf		MACH_MSM7X30_SURF	MSM7X30_SURF		2679

Hi Russell,

ping :)

fyi im working on a linux and uboot port on the linkstation ls-chlv2 and ls-
xhl. unfortunately uboot is following linux' mach-types.h so i need to get 
this into linux before my uboot support can be merged upstream.

-- 
Michael

[PATCH] ARM: Add lsxhl machine type to mach-types

[Russell King - ARM Linux]

On Sat, Nov 12, 2011 at 05:02:15PM +0100, Michael Walle wrote:
> Am Montag 07 November 2011, 21:54:11 schrieb Michael Walle:
> > (Re-)add Buffalo Linkstation Pro LS-XHL machine type.
> > 
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> >  arch/arm/tools/mach-types |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
> > index 5bdeef9..d50917e 100644
> > --- a/arch/arm/tools/mach-types
> > +++ b/arch/arm/tools/mach-types
> > @@ -458,6 +458,7 @@ mityomapl138		MACH_MITYOMAPL138	
> MITYOMAPL138		2650
> >  guruplug		MACH_GURUPLUG		GURUPLUG		2659
> >  spear310		MACH_SPEAR310		SPEAR310		2660
> >  spear320		MACH_SPEAR320		SPEAR320		2661
> > +lsxhl			MACH_LSXHL		LSXHL			
> 2663
> >  aquila			MACH_AQUILA		AQUILA			
> 2676
> >  sheeva_esata		MACH_ESATA_SHEEVAPLUG	ESATA_SHEEVAPLUG	2678
> >  msm7x30_surf		MACH_MSM7X30_SURF	MSM7X30_SURF		2679
> 
> Hi Russell,
> 
> ping :)
> 
> fyi im working on a linux and uboot port on the linkstation ls-chlv2 and ls-
> xhl. unfortunately uboot is following linux' mach-types.h so i need to get 
> this into linux before my uboot support can be merged upstream.

Please read the comments at the top of the file:

# This is a cut-down version of the file; it contains only machines that
# are merged into mainline or have been edited in the machine database
# within the last 12 months.  References to machine_is_NAME() do not count!

It gives you the criteria for entries being removed from the file.

What guarantee do we have that support for this platform will be found
to be acceptable (in it's non-DT form) and will be accepted into mainline
(which is the basic requirement for the entry staying in the kernel's
version of this file.)

[PATCH] ARM: Add lsxhl machine type to mach-types

[Michael Walle]

Am Sonntag 13 November 2011, 00:01:57 schrieb Russell King - ARM Linux:
> Please read the comments at the top of the file:
sorry, read that over.

> # This is a cut-down version of the file; it contains only machines that
> # are merged into mainline or have been edited in the machine database
> # within the last 12 months.  References to machine_is_NAME() do not count!
> 
> It gives you the criteria for entries being removed from the file.
> 
> What guarantee do we have that support for this platform will be found
> to be acceptable (in it's non-DT form) and will be accepted into mainline
> (which is the basic requirement for the entry staying in the kernel's
> version of this file.)
ok, if only non-dt machine entries will stay in this file, this request is 
already obsolete. my initial non-dt support patch was NAK'ed because the 
kirkwood arch doesn't accept old-fashioned board support patches anymore.

then, i guess, the problem is on the uboot side, at least if they want to 
support both device tree based and old-fashioned setup code (eg. backported 
device support.)

-- 
Michael

[PATCH] ARM: Add lsxhl machine type to mach-types

[Russell King - ARM Linux]

On Sun, Nov 13, 2011 at 12:40:42AM +0100, Michael Walle wrote:
> then, i guess, the problem is on the uboot side, at least if they want to 
> support both device tree based and old-fashioned setup code (eg. backported 
> device support.)

If uboot wants to carry the full list, rather than copying it from
the kernel source, they should be going straight to the main source
of the file (which is given inside the file itself.)

Otherwise, if they want to be purely dependent on the version shipped
with the kernel, which will have entries for platforms not merged into
the kernel source deleted from it once they're older than 12 months -
but which may be in u-boot, they can continue taking it out of the
kernel tree.  I think that's sub-optimal as they'll see regressions
from time to time when platforms have been merged into u-boot but not
the kernel.

[PATCH] ARM: Add lsxhl machine type to mach-types

[Marek Vasut]

> On Sun, Nov 13, 2011 at 12:40:42AM +0100, Michael Walle wrote:
> > then, i guess, the problem is on the uboot side, at least if they want to
> > support both device tree based and old-fashioned setup code (eg.
> > backported device support.)
> 
> If uboot wants to carry the full list, rather than copying it from
> the kernel source, they should be going straight to the main source
> of the file (which is given inside the file itself.)
> 
> Otherwise, if they want to be purely dependent on the version shipped
> with the kernel, which will have entries for platforms not merged into
> the kernel source deleted from it once they're older than 12 months -
> but which may be in u-boot, they can continue taking it out of the
> kernel tree.  I think that's sub-optimal as they'll see regressions
> from time to time when platforms have been merged into u-boot but not
> the kernel.

Hey,

U-Boot follows the in-kernel mach-types file. We had a few issues with boards 
not building due to the removal of old mach types.

So basically, you should fix your patches for the Linkstation to support DT, 
resubmit them, get them mainline, then enable DT in U-Boot and boot that way. I 
see now problem.

And if your platform is a broken crap, please define CONFIG_MACH_TYPE 
MACH_TYPE_SOMETHING and MACH_TYPE_SOMETHING in your include/configs/something.h 
config file.

M

[PATCH] ARM: Add lsxhl machine type to mach-types

[Russell King - ARM Linux]

On Sun, Nov 13, 2011 at 01:29:56AM +0100, Marek Vasut wrote:
> > On Sun, Nov 13, 2011 at 12:40:42AM +0100, Michael Walle wrote:
> > > then, i guess, the problem is on the uboot side, at least if they want to
> > > support both device tree based and old-fashioned setup code (eg.
> > > backported device support.)
> > 
> > If uboot wants to carry the full list, rather than copying it from
> > the kernel source, they should be going straight to the main source
> > of the file (which is given inside the file itself.)
> > 
> > Otherwise, if they want to be purely dependent on the version shipped
> > with the kernel, which will have entries for platforms not merged into
> > the kernel source deleted from it once they're older than 12 months -
> > but which may be in u-boot, they can continue taking it out of the
> > kernel tree.  I think that's sub-optimal as they'll see regressions
> > from time to time when platforms have been merged into u-boot but not
> > the kernel.
> 
> Hey,
> 
> U-Boot follows the in-kernel mach-types file. We had a few issues with boards 
> not building due to the removal of old mach types.

As the kernel version of the file is now specifically customised for
the kernel, u-boot should _not_ follow the kernel version anymore, as
I pointed out.  u-boot need to change this policy of theirs.

The file has always been and remains available on the web.  There's
absolutely no need for u-boot to take the customised version from the
kernel source.

[PATCH] ARM: Add lsxhl machine type to mach-types

[Marek Vasut]

> On Sun, Nov 13, 2011 at 01:29:56AM +0100, Marek Vasut wrote:
> > > On Sun, Nov 13, 2011 at 12:40:42AM +0100, Michael Walle wrote:
> > > > then, i guess, the problem is on the uboot side, at least if they
> > > > want to support both device tree based and old-fashioned setup code
> > > > (eg. backported device support.)
> > > 
> > > If uboot wants to carry the full list, rather than copying it from
> > > the kernel source, they should be going straight to the main source
> > > of the file (which is given inside the file itself.)
> > > 
> > > Otherwise, if they want to be purely dependent on the version shipped
> > > with the kernel, which will have entries for platforms not merged into
> > > the kernel source deleted from it once they're older than 12 months -
> > > but which may be in u-boot, they can continue taking it out of the
> > > kernel tree.  I think that's sub-optimal as they'll see regressions
> > > from time to time when platforms have been merged into u-boot but not
> > > the kernel.
> > 
> > Hey,
> > 
> > U-Boot follows the in-kernel mach-types file. We had a few issues with
> > boards not building due to the removal of old mach types.
> 
> As the kernel version of the file is now specifically customised for
> the kernel, u-boot should _not_ follow the kernel version anymore, as
> I pointed out.  u-boot need to change this policy of theirs.

Why would that be so? If the users want to support the boards and the boards are 
broken/removed from linux, they just define the mach id by hand. That also makes 
it easier to detect such boards. It is also a warning that noone gives a crap 
about such boards and they might as well soon be removed from uboot too.
> 
> The file has always been and remains available on the web.  There's
> absolutely no need for u-boot to take the customised version from the
> kernel source.

[PATCH] ARM: Add lsxhl machine type to mach-types

[Russell King - ARM Linux]

On Sun, Nov 13, 2011 at 05:20:22PM +0100, Marek Vasut wrote:
> > On Sun, Nov 13, 2011 at 01:29:56AM +0100, Marek Vasut wrote:
> > > > On Sun, Nov 13, 2011 at 12:40:42AM +0100, Michael Walle wrote:
> > > > > then, i guess, the problem is on the uboot side, at least if they
> > > > > want to support both device tree based and old-fashioned setup code
> > > > > (eg. backported device support.)
> > > > 
> > > > If uboot wants to carry the full list, rather than copying it from
> > > > the kernel source, they should be going straight to the main source
> > > > of the file (which is given inside the file itself.)
> > > > 
> > > > Otherwise, if they want to be purely dependent on the version shipped
> > > > with the kernel, which will have entries for platforms not merged into
> > > > the kernel source deleted from it once they're older than 12 months -
> > > > but which may be in u-boot, they can continue taking it out of the
> > > > kernel tree.  I think that's sub-optimal as they'll see regressions
> > > > from time to time when platforms have been merged into u-boot but not
> > > > the kernel.
> > > 
> > > Hey,
> > > 
> > > U-Boot follows the in-kernel mach-types file. We had a few issues with
> > > boards not building due to the removal of old mach types.
> > 
> > As the kernel version of the file is now specifically customised for
> > the kernel, u-boot should _not_ follow the kernel version anymore, as
> > I pointed out.  u-boot need to change this policy of theirs.
> 
> Why would that be so? If the users want to support the boards and the boards are 
> broken/removed from linux, they just define the mach id by hand. That also makes 
> it easier to detect such boards. It is also a warning that noone gives a crap 
> about such boards and they might as well soon be removed from uboot too.

That is a policy for uboot folk to decide upon.

However, given that the policy for the kernel changed from "lets include
everything" to "lets include only a limited amount" effectively that
change of kernel policy has also changed the uboot policy without any
uboot people apparantly being aware of the change.

If uboot people are happy with the idea that entries get removed, then
fine - but be absolutely clear that I won't be adding entries to the
kernel's file to satisfy the cravings of someone in the uboot camp
complaining that their entry has been deleted for whatever reason.

And note that _sometimes_ entries get deleted not because they aren't
in mainline, but because they were found to be non-conformant and were
missed during the period when I manually checked them.  So, the lack of
an entry in the kernel's file _doesn't_ actually tell uboot why it was
removed - it might even still be in the mainline kernel.

Case in point there: Sheeva eSATA platform.