[PATCH] ARM: remove last use of CONFIG_CPU_ARM710

[PATCH] ARM: remove last use of CONFIG_CPU_ARM710

[Paul Bolle]

Support for ARM710 CPUs was removed in v3.5. Now remove the last code
depending on its Kconfig macro.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Untested. Note that cpu_arm7_data_abort was also removed.

 arch/arm/include/asm/glue-df.h | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h
index 8cacbcd..75e6908 100644
--- a/arch/arm/include/asm/glue-df.h
+++ b/arch/arm/include/asm/glue-df.h
@@ -31,14 +31,6 @@
 #undef CPU_DABORT_HANDLER
 #undef MULTI_DABORT
 
-#if defined(CONFIG_CPU_ARM710)
-# ifdef CPU_DABORT_HANDLER
-#  define MULTI_DABORT 1
-# else
-#  define CPU_DABORT_HANDLER cpu_arm7_data_abort
-# endif
-#endif
-
 #ifdef CONFIG_CPU_ABRT_LV4T
 # ifdef CPU_DABORT_HANDLER
 #  define MULTI_DABORT 1
-- 
1.7.11.7

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Paul Bolle]

Support for ARM710 CPUs was removed in v3.5. Now remove the last code
depending on its Kconfig macro.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
First submitted in March 2103. Still untested. Please note that
cpu_arm7_data_abort was also removed in v3.5.

 arch/arm/include/asm/glue-df.h | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h
index 6b70f1b46a6e..04e18b656659 100644
--- a/arch/arm/include/asm/glue-df.h
+++ b/arch/arm/include/asm/glue-df.h
@@ -31,14 +31,6 @@
 #undef CPU_DABORT_HANDLER
 #undef MULTI_DABORT
 
-#if defined(CONFIG_CPU_ARM710)
-# ifdef CPU_DABORT_HANDLER
-#  define MULTI_DABORT 1
-# else
-#  define CPU_DABORT_HANDLER cpu_arm7_data_abort
-# endif
-#endif
-
 #ifdef CONFIG_CPU_ABRT_EV4
 # ifdef CPU_DABORT_HANDLER
 #  define MULTI_DABORT 1
-- 
1.9.0

Re: [PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Alexander Shiyan]

Wed, 14 May 2014 10:24:25 +0200 ?? Paul Bolle <pebolle@tiscali.nl>:
> Support for ARM710 CPUs was removed in v3.5. Now remove the last code
> depending on its Kconfig macro.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> First submitted in March 2103. Still untested. Please note that
> cpu_arm7_data_abort was also removed in v3.5.

Russell usually apply such patches via the tracker.

http://www.arm.linux.org.uk/developer/patches/

---

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Paul Bolle]

On Wed, 2014-05-14 at 12:48 +0400, Alexander Shiyan wrote:
> Russell usually apply such patches via the tracker.
> 
> http://www.arm.linux.org.uk/developer/patches/

And that page tells me
    Please note: this is not a patch review system;
    please submit all patches to the linux-arm-kernel mailing
    list for community review prior to submission here.

I've not been notified that my patch was added to that tracker, so it is
appropriate to resend.


Paul Bolle

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Arnd Bergmann]

On Wednesday 14 May 2014 10:24:25 Paul Bolle wrote:
> Support for ARM710 CPUs was removed in v3.5. Now remove the last code
> depending on its Kconfig macro.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> First submitted in March 2103. Still untested. Please note that
> cpu_arm7_data_abort was also removed in v3.5.
> 

'git grep -i arm710' tells me that there is also some arm710
specific code in  arch/arm/mm/proc-arm720.S that we may want to
remove along with this.

The DT binding should probably remain untouched though, I think it's
correct to document the string.

	Arnd

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Paul Bolle]

On Wed, 2014-05-14 at 11:17 +0200, Arnd Bergmann wrote:
> 'git grep -i arm710' tells me that there is also some arm710
> specific code in  arch/arm/mm/proc-arm720.S that we may want to
> remove along with this.
> 
> The DT binding should probably remain untouched though, I think it's
> correct to document the string.

That seems to be cpu_arm710_name, __arm710_setup, and everything called
by __arm710_setup. Cleaning that up (as a separate patch) appears to be
trivial. If I do that it would be (sort of educated) guesswork. But I
don't mind doing it. What do you prefer?


Paul Bolle

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Arnd Bergmann]

On Wednesday 14 May 2014 11:25:50 Paul Bolle wrote:
> On Wed, 2014-05-14 at 11:17 +0200, Arnd Bergmann wrote:
> > 'git grep -i arm710' tells me that there is also some arm710
> > specific code in  arch/arm/mm/proc-arm720.S that we may want to
> > remove along with this.
> > 
> > The DT binding should probably remain untouched though, I think it's
> > correct to document the string.
> 
> That seems to be cpu_arm710_name, __arm710_setup, and everything called
> by __arm710_setup. Cleaning that up (as a separate patch) appears to be
> trivial. If I do that it would be (sort of educated) guesswork. But I
> don't mind doing it. What do you prefer?

I think that would be great. For the first patch, please add 

Acked-by: Arnd Bergmann <arnd@arndb.de>

Once the second patch is reviewed, please add them both to Russell's
patch tracker.

	Arnd

[PATCH] ARM: remove ARM710 specific assembler code

[Paul Bolle]

Support for ARM710 CPUs was removed in v3.5. But a few lines of ARM710
specific assembler code were left in the tree. Remove these too.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
This minor cleanup was suggested by Arnd. This patch is mostly
guesswork, as I already told Arnd, since I have never touched ARM
assembler before (as far as I can remember). Untested too! And this does
need testing.

 arch/arm/mm/proc-arm720.S | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/arch/arm/mm/proc-arm720.S b/arch/arm/mm/proc-arm720.S
index d42c37f9f5bc..6699f91a6a0f 100644
--- a/arch/arm/mm/proc-arm720.S
+++ b/arch/arm/mm/proc-arm720.S
@@ -116,34 +116,6 @@ ENTRY(cpu_arm720_reset)
 ENDPROC(cpu_arm720_reset)
 		.popsection
 
-	.type	__arm710_setup, #function
-__arm710_setup:
-	mov	r0, #0
-	mcr	p15, 0, r0, c7, c7, 0		@ invalidate caches
-#ifdef CONFIG_MMU
-	mcr	p15, 0, r0, c8, c7, 0		@ flush TLB (v4)
-#endif
-	mrc	p15, 0, r0, c1, c0		@ get control register
-	ldr	r5, arm710_cr1_clear
-	bic	r0, r0, r5
-	ldr	r5, arm710_cr1_set
-	orr	r0, r0, r5
-	mov	pc, lr				@ __ret (head.S)
-	.size	__arm710_setup, . - __arm710_setup
-
-	/*
-	 *  R
-	 * .RVI ZFRS BLDP WCAM
-	 * .... 0001 ..11 1101
-	 * 
-	 */
-	.type	arm710_cr1_clear, #object
-	.type	arm710_cr1_set, #object
-arm710_cr1_clear:
-	.word	0x0f3f
-arm710_cr1_set:
-	.word	0x013d
-
 	.type	__arm720_setup, #function
 __arm720_setup:
 	mov	r0, #0
@@ -177,7 +149,6 @@ arm720_crval:
 
 	string	cpu_arch_name, "armv4t"
 	string	cpu_elf_name, "v4"
-	string	cpu_arm710_name, "ARM710T"
 	string	cpu_arm720_name, "ARM720T"
 
 		.align
@@ -215,5 +186,4 @@ __\name\()_proc_info:
 		.size	__\name\()_proc_info, . - __\name\()_proc_info
 .endm
 
-	arm720_proc_info arm710, 0x41807100, 0xffffff00, cpu_arm710_name, __arm710_setup
 	arm720_proc_info arm720, 0x41807200, 0xffffff00, cpu_arm720_name, __arm720_setup
-- 
1.9.0

[PATCH] ARM: remove ARM710 specific assembler code

[Russell King - ARM Linux]

On Fri, May 16, 2014 at 11:29:58AM +0200, Paul Bolle wrote:
> Support for ARM710 CPUs was removed in v3.5. But a few lines of ARM710
> specific assembler code were left in the tree. Remove these too.
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> This minor cleanup was suggested by Arnd. This patch is mostly
> guesswork, as I already told Arnd, since I have never touched ARM
> assembler before (as far as I can remember). Untested too! And this does
> need testing.

NAK.

There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.

There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.

These are two completely different CPUs, the former was removed along with
the removal of ARMv3 support.  The latter remains because we still support
ARMv4.

This is a nice instance of arm-soc people thinking that they are somehow
authoritive for core ARM stuff...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH] ARM: remove ARM710 specific assembler code

[Paul Bolle]

On Fri, 2014-05-16 at 13:55 +0100, Russell King - ARM Linux wrote:
> There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.
> 
> There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.
> 
> These are two completely different CPUs, the former was removed along with
> the removal of ARMv3 support.  The latter remains because we still support
> ARMv4.

Thanks for taking the time to explain this. Next time I hope to be more
aware of the possibility of important differences between ARM CPUs that
have rather similar names.


Paul Bolle

[PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote:
> There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.
> 
> There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.
> 
> These are two completely different CPUs, the former was removed along with
> the removal of ARMv3 support.  The latter remains because we still support
> ARMv4.

BTW, while clearly this patch was removing code for the wrong reasons, I
think we should set a longer term timeline for getting rid of some of
old features. Let's say in 10 years time we remove everything ARMv4,
another 10 years ARMv5 and so on. We could make these milestones shorter
but it really depends on what people use, we should not force them out
of the kernel if still in use.

We can start with ARM core and SoC code that we suspect people haven't
used in a while (or at least not with mainline). We should not remove
them straight away but give some advanced warning. My proposal is to add
a CONFIG_DEPRECATED option and update it with a 2 year cadence. Code
that we want to remove will depend on DEPRECATED and explicitly not
covered by defconfig. This way we can get interested parties sending
patches to remove the DEPRECATED dependency. Something like this:

config DEPRECATED
	bool "Enable deprecated kernel features"
	help
	  Kernel features no longer in use are marked as DEPRECATED for
	  two years and removed at the end of this period. This option
	  should only be enabled explicitly and must not be included in
	  defconfig files. If you think a DEPRECATED kernel feature is
	  still needed, please contact the corresponding maintainers to
	  remove the DEPRECATED dependency.

	  The next scheduled DEPRECATED code removal is planned for 2016.

It would be even better if we make such option across the whole kernel,
especially since we have significant ARM SoC code into drivers.
Otherwise calling it ARM_DEPRECATED would work as well.

-- 
Catalin

[PATCH] ARM: remove ARM710 specific assembler code

[Russell King - ARM Linux]

On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote:
> On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote:
> > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.
> > 
> > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.
> > 
> > These are two completely different CPUs, the former was removed along with
> > the removal of ARMv3 support.  The latter remains because we still support
> > ARMv4.
> 
> BTW, while clearly this patch was removing code for the wrong reasons, I
> think we should set a longer term timeline for getting rid of some of
> old features. Let's say in 10 years time we remove everything ARMv4,
> another 10 years ARMv5 and so on. We could make these milestones shorter
> but it really depends on what people use, we should not force them out
> of the kernel if still in use.

I still use StrongARM based machines here, and I don't see that changing
unless some suitably designed ARM boards come my way which (a) offer the
same features and (b) out perform it.

The problem is that there's lots of ARM boards which satisfy (b) - the
iMX6 stuff clearly does - but hardly anything which satisfies (a).

There's also been some recent effort with SA1100 SoC code, so there's
also other interest there still.

So, ARMv4 is still very much in use with modern kernels.

The difference between what you're proposing and what happened to ARMv3
is that ARMv3 was broken for quite some time (we read from some of the
CP15 registers which are read-only in ARMv3) and no one ever raised a
problem with that.  So, after a sufficient period of time, it got removed
- and no one batted an eyelid.  That's the correct way to do it - allow
code to age, and if no one notices it's been broken, then it can be
removed.

That process is slightly broken by the automated build testing we now
have (provided people are looking at the results.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On 17 May 2014, at 10:46, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote:
>> On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote:
>>> There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.
>>> 
>>> There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.
>>> 
>>> These are two completely different CPUs, the former was removed along with
>>> the removal of ARMv3 support.  The latter remains because we still support
>>> ARMv4.
>> 
>> BTW, while clearly this patch was removing code for the wrong reasons, I
>> think we should set a longer term timeline for getting rid of some of
>> old features. Let's say in 10 years time we remove everything ARMv4,
>> another 10 years ARMv5 and so on. We could make these milestones shorter
>> but it really depends on what people use, we should not force them out
>> of the kernel if still in use.
> 
> I still use StrongARM based machines here, and I don't see that changing
> unless some suitably designed ARM boards come my way which (a) offer the
> same features and (b) out perform it.
> 
> The problem is that there's lots of ARM boards which satisfy (b) - the
> iMX6 stuff clearly does - but hardly anything which satisfies (a).
> 
> There's also been some recent effort with SA1100 SoC code, so there's
> also other interest there still.
> 
> So, ARMv4 is still very much in use with modern kernels.

That?s why I said maybe aim for removing it in 10 year. But if code is
still in use by that time, we keep it.

> The difference between what you're proposing and what happened to ARMv3
> is that ARMv3 was broken for quite some time (we read from some of the
> CP15 registers which are read-only in ARMv3) and no one ever raised a
> problem with that.  So, after a sufficient period of time, it got removed
> - and no one batted an eyelid.  That's the correct way to do it - allow
> code to age, and if no one notices it's been broken, then it can be
> removed.

I?m more for pro-actively ?breaking? it with a DEPRECATED
dependency. For example, if you suspect that some code like ARM710T is
no longer in use, we mark it and see if anyone complains about this over
a two years period. If not, it gets removed.

Waiting for code to get broken is another way but it?s less
predictable.

Catalin

[PATCH] ARM: remove ARM710 specific assembler code

[Russell King - ARM Linux]

On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote:
> > The difference between what you're proposing and what happened to ARMv3
> > is that ARMv3 was broken for quite some time (we read from some of the
> > CP15 registers which are read-only in ARMv3) and no one ever raised a
> > problem with that.  So, after a sufficient period of time, it got removed
> > - and no one batted an eyelid.  That's the correct way to do it - allow
> > code to age, and if no one notices it's been broken, then it can be
> > removed.
> 
> I?m more for pro-actively ?breaking? it with a DEPRECATED
> dependency. For example, if you suspect that some code like ARM710T is
> no longer in use, we mark it and see if anyone complains about this over
> a two years period. If not, it gets removed.
> 
> Waiting for code to get broken is another way but it?s less
> predictable.

When code being used gets broken, it's nice to think that we'll get
bug reports which will tell us if it's still being used.  The problem
with DEPRECATED is that it will get lost amongst all the thousands
of other config options and won't be noticed.  Just like EXPERIMENTAL
or any of the other similar options we've had.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On Sat, May 17, 2014 at 11:26:38AM +0100, Russell King - ARM Linux wrote:
> On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote:
> > > The difference between what you're proposing and what happened to ARMv3
> > > is that ARMv3 was broken for quite some time (we read from some of the
> > > CP15 registers which are read-only in ARMv3) and no one ever raised a
> > > problem with that.  So, after a sufficient period of time, it got removed
> > > - and no one batted an eyelid.  That's the correct way to do it - allow
> > > code to age, and if no one notices it's been broken, then it can be
> > > removed.
> > 
> > I?m more for pro-actively ?breaking? it with a DEPRECATED
> > dependency. For example, if you suspect that some code like ARM710T is
> > no longer in use, we mark it and see if anyone complains about this over
> > a two years period. If not, it gets removed.
> > 
> > Waiting for code to get broken is another way but it?s less
> > predictable.
> 
> When code being used gets broken, it's nice to think that we'll get
> bug reports which will tell us if it's still being used.

But if you don't get any reports, you can't really whether it's broken
(just because it compiles doesn't mean it still works). So we end up
with keeping code in the kernel for much longer than necessary.

> The problem
> with DEPRECATED is that it will get lost amongst all the thousands
> of other config options and won't be noticed.  Just like EXPERIMENTAL
> or any of the other similar options we've had.

DEPRECATED is meant for documenting the planned removal. If people
complain afterwards, it's their problem for not reporting it earlier.

But we can make it even clearer by adding "depends on n" for DEPRECATED
or just making it not user selectable, so that people would need to
actively change the Kconfig source. They can't complain they haven't
noticed.

-- 
Catalin

[PATCH] ARM: remove ARM710 specific assembler code

[Arnd Bergmann]

On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote:
> > The difference between what you're proposing and what happened to ARMv3
> > is that ARMv3 was broken for quite some time (we read from some of the
> > CP15 registers which are read-only in ARMv3) and no one ever raised a
> > problem with that.  So, after a sufficient period of time, it got removed
> > - and no one batted an eyelid.  That's the correct way to do it - allow
> > code to age, and if no one notices it's been broken, then it can be
> > removed.
> 
> I?m more for pro-actively ?breaking? it with a DEPRECATED
> dependency. For example, if you suspect that some code like ARM710T is
> no longer in use, we mark it and see if anyone complains about this over
> a two years period. If not, it gets removed.
> 
> Waiting for code to get broken is another way but it?s less
> predictable.

We used to have 'feature-removal-schedule.txt' file in the Documentation.
It never worked, and I don't see a reason to introduce something like that
again.

Yes, this means we will keep going through things that may or may not be
considered obsolete occasionally asking whether it's already dead. There
are a number of platforms we removed in the past years (e.g. shark,
h720x, bcmring, pnx4008, ixp2xxx, tcc8k and others before) and we haven't
had to revert any of those back. The rule has always been that even if
someone later comes and wants them back, we will revert the removal.
Others have been given temporary (e.g. gemini) or permanent (e.g. ixp4xx)
extensions, based on the feedback from the maintainers or remaining
users.

For the case of ARM710T, I think the last remaining user that can be
configured is mach-integrator, but I don't know if anybody even has that
CPU tile, or wants to keep using it. If Russell and Linus as the only
people that have cared about Integrator in the past years want to
cut down the number of supported CPUs, that would be a different matter:
quite a number of CPUs are not supported in any other platform.
Note that the integrator target in qemu does not support any ARM7, only
StrongARM, ARM9 or later. I also double-checked about mach-clps711x,
but I'm pretty sure those SoCs are all either ARM710a (no longer supported)
or ARM720T (quite active).

	Arnd

[PATCH] ARM: remove ARM710 specific assembler code

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140519 04:27]:
> On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote:
> 
> For the case of ARM710T, I think the last remaining user that can be
> configured is mach-integrator, but I don't know if anybody even has that
> CPU tile, or wants to keep using it. If Russell and Linus as the only
> people that have cared about Integrator in the past years want to
> cut down the number of supported CPUs, that would be a different matter:
> quite a number of CPUs are not supported in any other platform.
> Note that the integrator target in qemu does not support any ARM7, only
> StrongARM, ARM9 or later. I also double-checked about mach-clps711x,
> but I'm pretty sure those SoCs are all either ARM710a (no longer supported)
> or ARM720T (quite active).

Hmm I don't think mach-integrator is using ARM710T?

The ARM710T was done by NEC and was used by the Psion MX hardware.
It's very close to ARM720T as far as I remember so might as well keep
the CPU support for it as that's just a few lines of code in the
mainline kernel.

I don't think we have any mach directories using ARM710T, but I
would not be surprised if somebody comes along with device tree
based booting patches for Psion MX at some point.

Regards,

Tony

[PATCH] ARM: remove ARM710 specific assembler code

[Arnd Bergmann]

On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140519 04:27]:
> > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote:
> > 
> > For the case of ARM710T, I think the last remaining user that can be
> > configured is mach-integrator, but I don't know if anybody even has that
> > CPU tile, or wants to keep using it. If Russell and Linus as the only
> > people that have cared about Integrator in the past years want to
> > cut down the number of supported CPUs, that would be a different matter:
> > quite a number of CPUs are not supported in any other platform.
> > Note that the integrator target in qemu does not support any ARM7, only
> > StrongARM, ARM9 or later. I also double-checked about mach-clps711x,
> > but I'm pretty sure those SoCs are all either ARM710a (no longer supported)
> > or ARM720T (quite active).
> 
> Hmm I don't think mach-integrator is using ARM710T?

I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T
use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator.
Without any further information, I assumed that both might potentially be used.

> The ARM710T was done by NEC and was used by the Psion MX hardware.
> It's very close to ARM720T as far as I remember so might as well keep
> the CPU support for it as that's just a few lines of code in the
> mainline kernel.
> 
> I don't think we have any mach directories using ARM710T, but I
> would not be surprised if somebody comes along with device tree
> based booting patches for Psion MX at some point.

Of course, if someone does this, the CPU support would be the least
of their work ;-)

Just out of curiosity: was that NEC 710T a SoC that replaced the
CL/PS7110, or a standalone CPU that Psion combined with a custom
ASIC?

	Arnd

[PATCH] ARM: remove ARM710 specific assembler code

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140520 13:10]:
> On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140519 04:27]:
> > > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote:
> > > 
> > > For the case of ARM710T, I think the last remaining user that can be
> > > configured is mach-integrator, but I don't know if anybody even has that
> > > CPU tile, or wants to keep using it. If Russell and Linus as the only
> > > people that have cared about Integrator in the past years want to
> > > cut down the number of supported CPUs, that would be a different matter:
> > > quite a number of CPUs are not supported in any other platform.
> > > Note that the integrator target in qemu does not support any ARM7, only
> > > StrongARM, ARM9 or later. I also double-checked about mach-clps711x,
> > > but I'm pretty sure those SoCs are all either ARM710a (no longer supported)
> > > or ARM720T (quite active).
> > 
> > Hmm I don't think mach-integrator is using ARM710T?
> 
> I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T
> use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator.
> Without any further information, I assumed that both might potentially be used.
> 
> > The ARM710T was done by NEC and was used by the Psion MX hardware.
> > It's very close to ARM720T as far as I remember so might as well keep
> > the CPU support for it as that's just a few lines of code in the
> > mainline kernel.
> > 
> > I don't think we have any mach directories using ARM710T, but I
> > would not be surprised if somebody comes along with device tree
> > based booting patches for Psion MX at some point.
> 
> Of course, if someone does this, the CPU support would be the least
> of their work ;-)

Right :)
 
> Just out of curiosity: was that NEC 710T a SoC that replaced the
> CL/PS7110, or a standalone CPU that Psion combined with a custom
> ASIC?

I think 710T was a pin compatible clone of CL/PS7110 by NEC. The
device registers were different both from CL/PS7110 and 720T for
most part.

Regards,

Tony

[PATCH] ARM: remove ARM710 specific assembler code

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140522 11:41]:
> * Arnd Bergmann <arnd@arndb.de> [140520 13:10]:
> > On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote:
> > > * Arnd Bergmann <arnd@arndb.de> [140519 04:27]:
> > > > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote:
> > > > 
> > > > For the case of ARM710T, I think the last remaining user that can be
> > > > configured is mach-integrator, but I don't know if anybody even has that
> > > > CPU tile, or wants to keep using it. If Russell and Linus as the only
> > > > people that have cared about Integrator in the past years want to
> > > > cut down the number of supported CPUs, that would be a different matter:
> > > > quite a number of CPUs are not supported in any other platform.
> > > > Note that the integrator target in qemu does not support any ARM7, only
> > > > StrongARM, ARM9 or later. I also double-checked about mach-clps711x,
> > > > but I'm pretty sure those SoCs are all either ARM710a (no longer supported)
> > > > or ARM720T (quite active).
> > > 
> > > Hmm I don't think mach-integrator is using ARM710T?
> > 
> > I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T
> > use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator.
> > Without any further information, I assumed that both might potentially be used.
> > 
> > > The ARM710T was done by NEC and was used by the Psion MX hardware.
> > > It's very close to ARM720T as far as I remember so might as well keep
> > > the CPU support for it as that's just a few lines of code in the
> > > mainline kernel.
> > > 
> > > I don't think we have any mach directories using ARM710T, but I
> > > would not be surprised if somebody comes along with device tree
> > > based booting patches for Psion MX at some point.
> > 
> > Of course, if someone does this, the CPU support would be the least
> > of their work ;-)
> 
> Right :)
>  
> > Just out of curiosity: was that NEC 710T a SoC that replaced the
> > CL/PS7110, or a standalone CPU that Psion combined with a custom
> > ASIC?
> 
> I think 710T was a pin compatible clone of CL/PS7110 by NEC. The
> device registers were different both from CL/PS7110 and 720T for
> most part.

Oh and that also means that mach-integrator probably never used 710T
as we only have the 720T SoC registers in the mainline. From CPU
point of view 710T and 720T can be considered the same for most
part like we do.

Regards,

Tony

[PATCH] ARM: remove ARM710 specific assembler code

[One Thousand Gnomes]

> old features. Let's say in 10 years time we remove everything ARMv4,
> another 10 years ARMv5 and so on. We could make these milestones shorter
> but it really depends on what people use, we should not force them out
> of the kernel if still in use.

Why do you care ? Worry about it at the point nobody can remember needing
the support, or when it creates some horrible situation that is painful
to keep supporting and nobody seems to care. We've only recently dropped
80386 support, and we still support MC68000.

Or just wait until 2038 approaches and the 32bit panic stations begins,
then clean out 8)

Alan

[PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On Tue, May 20, 2014 at 04:48:19PM +0100, One Thousand Gnomes wrote:
> > old features. Let's say in 10 years time we remove everything ARMv4,
> > another 10 years ARMv5 and so on. We could make these milestones shorter
> > but it really depends on what people use, we should not force them out
> > of the kernel if still in use.
> 
> Why do you care ?

For now, just some negative diffstats in the arm tree ;). Longer term,
supporting only ARMv6+ could bring further core arm code clean-up but
that's not planned for another ~20 years.

> Worry about it at the point nobody can remember needing
> the support, or when it creates some horrible situation that is painful
> to keep supporting and nobody seems to care. We've only recently dropped
> 80386 support, and we still support MC68000.

It's not necessarily how far back we go but rather the wide variation in
ARM processors implementation, especially for the older architecture
versions, and not knowing whether the code still works since no-one
seems to remember having such hardware.

> Or just wait until 2038 approaches and the 32bit panic stations begins,
> then clean out 8)

This kind of matches my proposal to remove ARMv5 support in 20 years
(though we still keep ARMv6 and ARMv7 with 32-bit).

Anyway, the feedback seems to be that we keep them around until they can
no longer be supported (which probably means compiled).

-- 
Catalin

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Paul Bolle]

On Wed, 2014-05-14 at 11:28 +0200, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 11:25:50 Paul Bolle wrote:
> > On Wed, 2014-05-14 at 11:17 +0200, Arnd Bergmann wrote:
> > > 'git grep -i arm710' tells me that there is also some arm710
> > > specific code in  arch/arm/mm/proc-arm720.S that we may want to
> > > remove along with this.
> > > 
> > > The DT binding should probably remain untouched though, I think it's
> > > correct to document the string.
> > 
> > That seems to be cpu_arm710_name, __arm710_setup, and everything called
> > by __arm710_setup. Cleaning that up (as a separate patch) appears to be
> > trivial. If I do that it would be (sort of educated) guesswork. But I
> > don't mind doing it. What do you prefer?
> 
> I think that would be great. For the first patch, please add 
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Once the second patch is reviewed, please add them both to Russell's
> patch tracker.

Well, at least that second patch triggered a nice conversation. So I
should now add the first patch (with your ACK) to the tracker?


Paul Bolle

[PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710

[Arnd Bergmann]

On Friday 23 May 2014 11:07:54 Paul Bolle wrote:
> On Wed, 2014-05-14 at 11:28 +0200, Arnd Bergmann wrote:
> > On Wednesday 14 May 2014 11:25:50 Paul Bolle wrote:
> > > On Wed, 2014-05-14 at 11:17 +0200, Arnd Bergmann wrote:
> > > > 'git grep -i arm710' tells me that there is also some arm710
> > > > specific code in  arch/arm/mm/proc-arm720.S that we may want to
> > > > remove along with this.
> > > > 
> > > > The DT binding should probably remain untouched though, I think it's
> > > > correct to document the string.
> > > 
> > > That seems to be cpu_arm710_name, __arm710_setup, and everything called
> > > by __arm710_setup. Cleaning that up (as a separate patch) appears to be
> > > trivial. If I do that it would be (sort of educated) guesswork. But I
> > > don't mind doing it. What do you prefer?
> > 
> > I think that would be great. For the first patch, please add 
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > Once the second patch is reviewed, please add them both to Russell's
> > patch tracker.
> 
> Well, at least that second patch triggered a nice conversation. So I
> should now add the first patch (with your ACK) to the tracker?

Yes, please do that.

	Arnd