ARM: Add lsxhl machine type to mach-types

PATCH New Michael Walle 3 participants 9 messages Nov 7, 2011 – Nov 13, 2011 Arm (32-bit)

lore

Share & tools

lore

Michael Walle

author

2011-11-07 20:54 UTC #0 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

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

Signed-off-by Michael Walle <[email protected]>

---
 arch/arm/tools/mach-types |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/tools/mach-types +1 -0

index 5bdeef9..d50917e 100644
@@ -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

Signature · 1 line

1.7.2.5

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.

Signature · 1 line

Michael

Russell King - ARM Linux

2011-11-12 23:01 UTC #2 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 24 lines · Michael Walle

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

Quoted 7 lines

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.)

Michael Walle

author

2011-11-12 23:40 UTC #3 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Am Sonntag 13 November 2011, 00:01:57 schrieb Russell King - ARM Linux:

Quoted 1 line

Please read the comments at the top of the file:

sorry, read that over.

Quoted 10 lines

# 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.)

Signature · 1 line

Michael

Russell King - ARM Linux

2011-11-12 23:55 UTC #4 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 3 lines · Michael Walle

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.

Marek Vasut

2011-11-13 00:29 UTC #5 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 9 lines · Michael Walle

Quoted 3 lines
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.)

Quoted 7 lines

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.

Russell King - ARM Linux

2011-11-13 08:28 UTC #6 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 17 lines · Marek Vasut

Quoted 9 lines · Michael Walle
Quoted 3 lines
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.)
Quoted 7 lines
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.

Quoted 4 lines

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.

Marek Vasut

2011-11-13 16:20 UTC #7 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 18 lines · Marek Vasut

Quoted 17 lines
Quoted 16 lines · Michael Walle
Quoted 3 lines
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.

Quoted 8 lines

Quoted 4 lines
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.

Quoted 4 lines

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.

Russell King - ARM Linux

2011-11-13 21:06 UTC #8 lore raw

PATCH 1/1 ARM: Add lsxhl machine type to mach-types

Quoted 23 lines · Marek Vasut

Quoted 23 lines · Marek Vasut
Quoted 21 lines
Quoted 9 lines · Michael Walle
Quoted 3 lines
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.)
Quoted 7 lines
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.

Quoted 8 lines

Quoted 3 lines
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.