[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Nicolas Pitre]

Commit 5be9fc23cd ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
IRQ numbers by one but didn't update the get_irqnr_and_base macro
accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
is not defined.

Signed-off-by: Nicolas Pitre <nico@linaro.org>

diff --git a/arch/arm/mach-orion5x/include/mach/entry-macro.S b/arch/arm/mach-orion5x/include/mach/entry-macro.S
index 79eb502a1e..73919a36b5 100644
--- a/arch/arm/mach-orion5x/include/mach/entry-macro.S
+++ b/arch/arm/mach-orion5x/include/mach/entry-macro.S
@@ -21,5 +21,5 @@
 	@ find cause bits that are unmasked
 	ands	\irqstat, \irqstat, \tmp	@ clear Z flag if any
 	clzne	\irqnr,	\irqstat		@ calc irqnr
-	rsbne	\irqnr, \irqnr, #31
+	rsbne	\irqnr, \irqnr, #32
 	.endm

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Jason Cooper]

On Sun, Nov 22, 2015 at 10:44:19PM -0500, Nicolas Pitre wrote:
> Commit 5be9fc23cd ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
> IRQ numbers by one but didn't update the get_irqnr_and_base macro
> accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
> is not defined.
> 
> Signed-off-by: Nicolas Pitre <nico@linaro.org>

Applied to mvebu/fixes with minor tweak to the subject line and Cc's to
stable back to v4.2.

thx,

Jason.

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Nicolas Pitre]

On Wed, 25 Nov 2015, Jason Cooper wrote:

> On Sun, Nov 22, 2015 at 10:44:19PM -0500, Nicolas Pitre wrote:
> > Commit 5be9fc23cd ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
> > IRQ numbers by one but didn't update the get_irqnr_and_base macro
> > accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
> > is not defined.
> > 
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> 
> Applied to mvebu/fixes with minor tweak to the subject line and Cc's to
> stable back to v4.2.

Note that the patch this provides a fix for was introduced in v4.2, but 
it itself was marked for stable. So if commit 5be9fc23cd was backported 
back to v3.18 then this patch should also be backported to the same 
stable versions.

Same thing for the Dove variant.


Nicolas

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Jason Cooper]

On Wed, Nov 25, 2015 at 09:54:05AM -0500, Nicolas Pitre wrote:
> On Wed, 25 Nov 2015, Jason Cooper wrote:
> 
> > On Sun, Nov 22, 2015 at 10:44:19PM -0500, Nicolas Pitre wrote:
> > > Commit 5be9fc23cd ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
> > > IRQ numbers by one but didn't update the get_irqnr_and_base macro
> > > accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
> > > is not defined.
> > > 
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > 
> > Applied to mvebu/fixes with minor tweak to the subject line and Cc's to
> > stable back to v4.2.
> 
> Note that the patch this provides a fix for was introduced in v4.2, but 
> it itself was marked for stable. So if commit 5be9fc23cd was backported 
> back to v3.18 then this patch should also be backported to the same 
> stable versions.
> 
> Same thing for the Dove variant.

Crap.  Nice catch.  I'll update *before* pushing.  :)

thx,

Jason.

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Nicolas Pitre]

On Wed, 25 Nov 2015, Jason Cooper wrote:

> On Wed, Nov 25, 2015 at 09:54:05AM -0500, Nicolas Pitre wrote:
> > On Wed, 25 Nov 2015, Jason Cooper wrote:
> > 
> > > On Sun, Nov 22, 2015 at 10:44:19PM -0500, Nicolas Pitre wrote:
> > > > Commit 5be9fc23cd ("ARM: orion5x: fix legacy orion5x IRQ numbers") shifted
> > > > IRQ numbers by one but didn't update the get_irqnr_and_base macro
> > > > accordingly.  This macro is involved when CONFIG_MULTI_IRQ_HANDLER
> > > > is not defined.
> > > > 
> > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > 
> > > Applied to mvebu/fixes with minor tweak to the subject line and Cc's to
> > > stable back to v4.2.
> > 
> > Note that the patch this provides a fix for was introduced in v4.2, but 
> > it itself was marked for stable. So if commit 5be9fc23cd was backported 
> > back to v3.18 then this patch should also be backported to the same 
> > stable versions.
> > 
> > Same thing for the Dove variant.
> 
> Crap.  Nice catch.  I'll update *before* pushing.  :)

BTW, mv78xx0 is still broken wrt this IRQ #0 usage.  Is it possible that 
no one uses it?  It is a weird not-completely-SMP architecture that 
lacks cache coherency support between CPU cores. To fully use both 
cores, we'd need to have two independent Linux instances with memory 
partitioning and this was never implemented. I'm unaware of any product 
using Linux on that SOC either.  My own mv78xx0 dev board took the way 
of the recycling facility a while ago given the lack of interest.

Should we "fix" it by removing it outright?


Nicolas

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Andrew Lunn]

> BTW, mv78xx0 is still broken wrt this IRQ #0 usage.  Is it possible that 
> no one uses it?  It is a weird not-completely-SMP architecture that 
> lacks cache coherency support between CPU cores. To fully use both 
> cores, we'd need to have two independent Linux instances with memory 
> partitioning and this was never implemented. I'm unaware of any product 
> using Linux on that SOC either.  My own mv78xx0 dev board took the way 
> of the recycling facility a while ago given the lack of interest.
> 
> Should we "fix" it by removing it outright?

I think it was at the Edinburgh kernel summit/ELCE i met somebody
still using it. If i remember correctly, Linux on one core, and
something else on the other. That was two years ago. I've not heard
anything since.

	 Andrew

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Jason Cooper]

On Wed, Nov 25, 2015 at 10:38:03AM -0500, Nicolas Pitre wrote:
...
> BTW, mv78xx0 is still broken wrt this IRQ #0 usage.  Is it possible that 
> no one uses it?  It is a weird not-completely-SMP architecture that 
> lacks cache coherency support between CPU cores. To fully use both 
> cores, we'd need to have two independent Linux instances with memory 
> partitioning and this was never implemented. I'm unaware of any product 
> using Linux on that SOC either.  My own mv78xx0 dev board took the way 
> of the recycling facility a while ago given the lack of interest.
> 
> Should we "fix" it by removing it outright?

The only users I know of were Debian.  They had their ARM build servers
running on some.  They have since been upgraded thanks to kind
donations.  :-)

thx,

Jason.

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Nicolas Pitre]

On Wed, 25 Nov 2015, Jason Cooper wrote:

> On Wed, Nov 25, 2015 at 10:38:03AM -0500, Nicolas Pitre wrote:
> ...
> > BTW, mv78xx0 is still broken wrt this IRQ #0 usage.  Is it possible that 
> > no one uses it?  It is a weird not-completely-SMP architecture that 
> > lacks cache coherency support between CPU cores. To fully use both 
> > cores, we'd need to have two independent Linux instances with memory 
> > partitioning and this was never implemented. I'm unaware of any product 
> > using Linux on that SOC either.  My own mv78xx0 dev board took the way 
> > of the recycling facility a while ago given the lack of interest.
> > 
> > Should we "fix" it by removing it outright?
> 
> The only users I know of were Debian.  They had their ARM build servers
> running on some.  They have since been upgraded thanks to kind
> donations.  :-)

I can tell you that those mv78xx0 build servers were also donations. The 
same type of board I retired from my desk.


Nicolas

[PATCH] ARM: mach-orion5x: fix legacy get_irqnr_and_base

[Nicolas Pitre]

On Wed, 25 Nov 2015, Andrew Lunn wrote:

> > BTW, mv78xx0 is still broken wrt this IRQ #0 usage.  Is it possible that 
> > no one uses it?  It is a weird not-completely-SMP architecture that 
> > lacks cache coherency support between CPU cores. To fully use both 
> > cores, we'd need to have two independent Linux instances with memory 
> > partitioning and this was never implemented. I'm unaware of any product 
> > using Linux on that SOC either.  My own mv78xx0 dev board took the way 
> > of the recycling facility a while ago given the lack of interest.
> > 
> > Should we "fix" it by removing it outright?
> 
> I think it was at the Edinburgh kernel summit/ELCE i met somebody
> still using it. If i remember correctly, Linux on one core, and
> something else on the other. That was two years ago. I've not heard
> anything since.

Any chance that somebody would still be interested in running latest 
mainline on it?

The alternative is to remove it and see if someone complains. Bringing 
it back would be just one git revert away.


Nicolas