| Message ID | alpine.LFD.2.20.1511222240150.22569@knanqh.ubzr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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.
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
> 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
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.
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
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
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
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>