[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Gregory CLEMENT]

From: Benjamin Cama <benoar@dolka.fr>

Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x.
Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for
dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including
dove) as the specific handler is needed to shift back IRQ numbers by
one.

[gregory.clement at free-electrons.com]: moved the select
MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke
the build for dove.

Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq")
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <stable@vger.kernel.org>
---
Hi Benjamin and Detlef,

I amended the patch from Benjamin as it break the build for
dove. Could you test it again wit this version?

Thanks,

Gregory

 arch/arm/Kconfig                          |  1 +
 arch/arm/mach-orion5x/include/mach/irqs.h | 64 +++++++++++++++----------------
 arch/arm/mach-orion5x/irq.c               |  4 +-
 3 files changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a750c1425c3a..a67e53a3ba31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -536,6 +536,7 @@ config ARCH_ORION5X
 	select MVEBU_MBUS
 	select PCI
 	select PLAT_ORION_LEGACY
+	select MULTI_IRQ_HANDLER
 	help
 	  Support for the following Marvell Orion 5x series SoCs:
 	  Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182),
diff --git a/arch/arm/mach-orion5x/include/mach/irqs.h b/arch/arm/mach-orion5x/include/mach/irqs.h
index a6fa9d8f12d8..2431d9923427 100644
--- a/arch/arm/mach-orion5x/include/mach/irqs.h
+++ b/arch/arm/mach-orion5x/include/mach/irqs.h
@@ -16,42 +16,42 @@
 /*
  * Orion Main Interrupt Controller
  */
-#define IRQ_ORION5X_BRIDGE		0
-#define IRQ_ORION5X_DOORBELL_H2C	1
-#define IRQ_ORION5X_DOORBELL_C2H	2
-#define IRQ_ORION5X_UART0		3
-#define IRQ_ORION5X_UART1		4
-#define IRQ_ORION5X_I2C			5
-#define IRQ_ORION5X_GPIO_0_7		6
-#define IRQ_ORION5X_GPIO_8_15		7
-#define IRQ_ORION5X_GPIO_16_23		8
-#define IRQ_ORION5X_GPIO_24_31		9
-#define IRQ_ORION5X_PCIE0_ERR		10
-#define IRQ_ORION5X_PCIE0_INT		11
-#define IRQ_ORION5X_USB1_CTRL		12
-#define IRQ_ORION5X_DEV_BUS_ERR		14
-#define IRQ_ORION5X_PCI_ERR		15
-#define IRQ_ORION5X_USB_BR_ERR		16
-#define IRQ_ORION5X_USB0_CTRL		17
-#define IRQ_ORION5X_ETH_RX		18
-#define IRQ_ORION5X_ETH_TX		19
-#define IRQ_ORION5X_ETH_MISC		20
-#define IRQ_ORION5X_ETH_SUM		21
-#define IRQ_ORION5X_ETH_ERR		22
-#define IRQ_ORION5X_IDMA_ERR		23
-#define IRQ_ORION5X_IDMA_0		24
-#define IRQ_ORION5X_IDMA_1		25
-#define IRQ_ORION5X_IDMA_2		26
-#define IRQ_ORION5X_IDMA_3		27
-#define IRQ_ORION5X_CESA		28
-#define IRQ_ORION5X_SATA		29
-#define IRQ_ORION5X_XOR0		30
-#define IRQ_ORION5X_XOR1		31
+#define IRQ_ORION5X_BRIDGE		(1 + 0)
+#define IRQ_ORION5X_DOORBELL_H2C	(1 + 1)
+#define IRQ_ORION5X_DOORBELL_C2H	(1 + 2)
+#define IRQ_ORION5X_UART0		(1 + 3)
+#define IRQ_ORION5X_UART1		(1 + 4)
+#define IRQ_ORION5X_I2C			(1 + 5)
+#define IRQ_ORION5X_GPIO_0_7		(1 + 6)
+#define IRQ_ORION5X_GPIO_8_15		(1 + 7)
+#define IRQ_ORION5X_GPIO_16_23		(1 + 8)
+#define IRQ_ORION5X_GPIO_24_31		(1 + 9)
+#define IRQ_ORION5X_PCIE0_ERR		(1 + 10)
+#define IRQ_ORION5X_PCIE0_INT		(1 + 11)
+#define IRQ_ORION5X_USB1_CTRL		(1 + 12)
+#define IRQ_ORION5X_DEV_BUS_ERR		(1 + 14)
+#define IRQ_ORION5X_PCI_ERR		(1 + 15)
+#define IRQ_ORION5X_USB_BR_ERR		(1 + 16)
+#define IRQ_ORION5X_USB0_CTRL		(1 + 17)
+#define IRQ_ORION5X_ETH_RX		(1 + 18)
+#define IRQ_ORION5X_ETH_TX		(1 + 19)
+#define IRQ_ORION5X_ETH_MISC		(1 + 20)
+#define IRQ_ORION5X_ETH_SUM		(1 + 21)
+#define IRQ_ORION5X_ETH_ERR		(1 + 22)
+#define IRQ_ORION5X_IDMA_ERR		(1 + 23)
+#define IRQ_ORION5X_IDMA_0		(1 + 24)
+#define IRQ_ORION5X_IDMA_1		(1 + 25)
+#define IRQ_ORION5X_IDMA_2		(1 + 26)
+#define IRQ_ORION5X_IDMA_3		(1 + 27)
+#define IRQ_ORION5X_CESA		(1 + 28)
+#define IRQ_ORION5X_SATA		(1 + 29)
+#define IRQ_ORION5X_XOR0		(1 + 30)
+#define IRQ_ORION5X_XOR1		(1 + 31)
 
 /*
  * Orion General Purpose Pins
  */
-#define IRQ_ORION5X_GPIO_START	32
+#define IRQ_ORION5X_GPIO_START	33
 #define NR_GPIO_IRQS		32
 
 #define NR_IRQS			(IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS)
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index cd4bac4d7e43..086ecb87d885 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -42,7 +42,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)
 	stat = readl_relaxed(MAIN_IRQ_CAUSE);
 	stat &= readl_relaxed(MAIN_IRQ_MASK);
 	if (stat) {
-		unsigned int hwirq = __fls(stat);
+		unsigned int hwirq = 1 + __fls(stat);
 		handle_IRQ(hwirq, regs);
 		return;
 	}
@@ -51,7 +51,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)
 
 void __init orion5x_init_irq(void)
 {
-	orion_irq_init(0, MAIN_IRQ_MASK);
+	orion_irq_init(1, MAIN_IRQ_MASK);
 
 #ifdef CONFIG_MULTI_IRQ_HANDLER
 	set_handle_irq(orion5x_legacy_handle_irq);
-- 
2.1.0

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Detlef Vollmann]

Hi Gregory,

On 08/15/15 16:17, Gregory CLEMENT wrote:
> I amended the patch from Benjamin as it break the build for
> dove. Could you test it again wit this version?
Tested with orion5x_defconfig on 4.2.0-rc6 and with my
own config on 4.1.2.
Looks good for both :-)

Thanks!
   Detlef

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Benjamin Cama]

Hi Gr?gory,

Le samedi 15 ao?t 2015 ? 16:17 +0200, Gregory CLEMENT a ?crit :
> I amended the patch from Benjamin as it break the build for
> dove. Could you test it again wit this version?

Thanks for the fix. I don't have much time to test it, but as the dts
conversion patch for my Linkstation Mini is in the series, this fix
shouldn't change anything, as the dts board file uses the generic
irqchip handler, isn't it?

Tell me if I missed something. Regards,
--
benjamin

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Gregory CLEMENT]

Hi Benjamin,

On 21/08/2015 13:33, Benjamin Cama wrote:
> Hi Gr?gory,
> 
> Le samedi 15 ao?t 2015 ? 16:17 +0200, Gregory CLEMENT a ?crit :
>> I amended the patch from Benjamin as it break the build for
>> dove. Could you test it again wit this version?
> 
> Thanks for the fix. I don't have much time to test it, but as the dts
> conversion patch for my Linkstation Mini is in the series, this fix
> shouldn't change anything, as the dts board file uses the generic
> irqchip handler, isn't it?
> 
> Tell me if I missed something. Regards,

Detlef tested it so it's OK. I was asking you also because it a patch
you wrote.


Thanks,

Gregory


> --
> benjamin
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Marc Zyngier]

On 19/06/15 02:38, Benjamin Cama wrote:
> Hi Marc,
> 
> Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
>> On 18/06/15 03:12, Benjamin Cama wrote:
>>> And I did it. And I stumbled upon commit
>>> a71b092a9c68685a270ebdde7b5986ba8787e575 ?ARM: Convert handle_IRQ to
>>> use __handle_domain_irq? (author Cc'ed). The new function
>>> __handle_domain_irq (in kernel/irq/irqdesc.c, which comes just two
>>> commits before, with 76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is
>>> subtly different from the one it replaces, handle_IRQ, as it checks if
>>> the irq is not 0 as well as checking for an upper bound. Removing the
>>> check for 0 makes my machine work again! But honestly, I do not know if
>>> a zero irq is legit, so I hope some more knowledgeable people will tell
>>> me if this is OK.
>>>
>>> -- >8 --
>>> Subject: [PATCH] Make __handle_domain_irq accept IRQ 0
>>>
>>> The same as handle_IRQ did before.
>>>
>>> Signed-off-by: Benjamin Cama <benoar@dolka.fr>
>>> ---
>>>  kernel/irq/irqdesc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
>>> index a1782f8..bfbeeb6 100644
>>> --- a/kernel/irq/irqdesc.c
>>> +++ b/kernel/irq/irqdesc.c
>>> @@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain 
>>> *domain, unsigned int hwirq,
>>>          * Some hardware gives randomly wrong interrupts.  Rather
>>>          * than crashing, do something sensible.
>>>          */
>>> -       if (unlikely(!irq || irq >= nr_irqs)) {
>>> +       if (unlikely(irq >= nr_irqs)) {
>>>                 ack_bad_irq(irq);
>>>                 ret = -EINVAL;
>>>         } else {
>>>
>>
>> Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been
>> for a very long time, and actually represents the lack of interrupt.
> 
> OK, sorry for the mistake, I didn't know. Shouldn't the IRQ
> initialization routine check this and warn the user that it may cause
> problems? ?Silently? making IRQ0 forbidden doesn't help for the
> platforms that are not fixed yet.

Well, this is hardly a new rule. It has been like this for quite a long
time: http://yarchive.net/comp/linux/zero.html

As for the checking and warning, this is on a very hot path, for an
error case that really shouldn't occur.

<rant>
I've also come to the conclusion that people often choose to ignore
warnings. It boots, so who cares? Funnily enough, they react when their
toy doesn't work any more.
</rant>

> 
>> The way you can address this is by making sure your favourite platform
>> does not use IRQ0 at all, which is done by not assuming that Linux IRQ
>> number (which is always completely virtual) is the same as the number
>> designating the actual HW interrupt line.
>>
>> For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by
>> one) for an example of such a (very simple) conversion. You'll need to
>> tweak irq.c too.
>>
>> Other commits for sa1100 will hopefully convince you to switch to irq
>> domains altogether. This will greatly facilitate a possible further
>> transition to DT if you wish to do so.
> 
> I read quite a bit about all this virtual/hardware IRQ stuff, and the
> irq domains, interesting. I see that orion5x seems to be one of the
> last platforms not using it (appart from DT-converted boards); is it a
> bad sign about its durability??

No, we have platforms that will most probably never be converted to DT,
and they are very far from rotting in the tree.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
> On 19/06/15 02:38, Benjamin Cama wrote:
> > Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
> >> Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been
> >> for a very long time, and actually represents the lack of interrupt.
> > 
> > OK, sorry for the mistake, I didn't know. Shouldn't the IRQ
> > initialization routine check this and warn the user that it may cause
> > problems? ?Silently? making IRQ0 forbidden doesn't help for the
> > platforms that are not fixed yet.
> 
> Well, this is hardly a new rule. It has been like this for quite a long
> time: http://yarchive.net/comp/linux/zero.html
> 
> As for the checking and warning, this is on a very hot path, for an
> error case that really shouldn't occur.

I was not talking about the irq handler, but the irq initialization
routine (on orion5x, orion_irq_init calls irq_alloc_generic_chip with
0), which takes the starting irq number and may warn when it is zero
(well, it may also start allocating at zero but never use it, so this
may not be a totally correct assumption, but I think this comes close,
and it's just a warning).

> <rant>
> I've also come to the conclusion that people often choose to ignore
> warnings. It boots, so who cares? Funnily enough, they react when their
> toy doesn't work any more.
> </rant>

Well, original Orion support seems to come from Marvell itself?

> > 
> >> The way you can address this is by making sure your favourite platform
> >> does not use IRQ0 at all, which is done by not assuming that Linux IRQ
> >> number (which is always completely virtual) is the same as the number
> >> designating the actual HW interrupt line.
> >>
> >> For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by
> >> one) for an example of such a (very simple) conversion. You'll need to
> >> tweak irq.c too.
> >>
> >> Other commits for sa1100 will hopefully convince you to switch to irq
> >> domains altogether. This will greatly facilitate a possible further
> >> transition to DT if you wish to do so.
> > 
> > I read quite a bit about all this virtual/hardware IRQ stuff, and the
> > irq domains, interesting. I see that orion5x seems to be one of the
> > last platforms not using it (appart from DT-converted boards); is it a
> > bad sign about its durability??
> 
> No, we have platforms that will most probably never be converted to DT,
> and they are very far from rotting in the tree.

Nice to know. One of the reasons for converting my board to DT was fear
that it may one day be mandatory. Is there any particular reason for
keeping some boards non-DT while still being maintained?

Regards,
--
benjamin

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Russell King - ARM Linux]

On Fri, Jun 19, 2015 at 02:16:34PM +0200, Benjamin Cama wrote:
> Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
> > On 19/06/15 02:38, Benjamin Cama wrote:
> > > Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
> > >> Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been
> > >> for a very long time, and actually represents the lack of interrupt.
> > > 
> > > OK, sorry for the mistake, I didn't know. Shouldn't the IRQ
> > > initialization routine check this and warn the user that it may cause
> > > problems? ?Silently? making IRQ0 forbidden doesn't help for the
> > > platforms that are not fixed yet.
> > 
> > Well, this is hardly a new rule. It has been like this for quite a long
> > time: http://yarchive.net/comp/linux/zero.html
> > 
> > As for the checking and warning, this is on a very hot path, for an
> > error case that really shouldn't occur.
> 
> I was not talking about the irq handler, but the irq initialization
> routine (on orion5x, orion_irq_init calls irq_alloc_generic_chip with
> 0), which takes the starting irq number and may warn when it is zero
> (well, it may also start allocating at zero but never use it, so this
> may not be a totally correct assumption, but I think this comes close,
> and it's just a warning).

It needs fixing nevertheless - arguments along the lines of "this used
to work" don't work for this topic.

The simple answer is to adjust the initialisation to bump the IRQ
numbers up by one, and them adjust the interrupt numbers in
arch/arm/mach-whatever/include/asm/irqs.h also up by one.  That's
far easier to do than spending ages trying to argue against the
"IRQ0 is not valid" issue, only to ultimately get nowhere, and end
up with that as the only way forward anyway.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Hi Russell,

Le 2015-06-19 15:13, Russell King - ARM Linux a ?crit?:
> On Fri, Jun 19, 2015 at 02:16:34PM +0200, Benjamin Cama wrote:
>> Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
>> > On 19/06/15 02:38, Benjamin Cama wrote:
>> > > Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
>> > >> Unfortunately, this is the wrong thing to do. IRQ0 is invalid, 
>> has been
>> > >> for a very long time, and actually represents the lack of 
>> interrupt.
>> > >
>> > > OK, sorry for the mistake, I didn't know. Shouldn't the IRQ
>> > > initialization routine check this and warn the user that it may 
>> cause
>> > > problems? ?Silently? making IRQ0 forbidden doesn't help for the
>> > > platforms that are not fixed yet.
>> >
>> > Well, this is hardly a new rule. It has been like this for quite a 
>> long
>> > time: http://yarchive.net/comp/linux/zero.html
>> >
>> > As for the checking and warning, this is on a very hot path, for 
>> an
>> > error case that really shouldn't occur.
>>
>> I was not talking about the irq handler, but the irq initialization
>> routine (on orion5x, orion_irq_init calls irq_alloc_generic_chip 
>> with
>> 0), which takes the starting irq number and may warn when it is zero
>> (well, it may also start allocating at zero but never use it, so 
>> this
>> may not be a totally correct assumption, but I think this comes 
>> close,
>> and it's just a warning).
>
> It needs fixing nevertheless - arguments along the lines of "this 
> used
> to work" don't work for this topic.
>
> The simple answer is to adjust the initialisation to bump the IRQ
> numbers up by one, and them adjust the interrupt numbers in
> arch/arm/mach-whatever/include/asm/irqs.h also up by one.  That's
> far easier to do than spending ages trying to argue against the
> "IRQ0 is not valid" issue, only to ultimately get nowhere, and end
> up with that as the only way forward anyway.

Do not misunderstand me: I am not at all for keeping the situation like 
this!
What I ask is just for users to be notified of this new requirement: 
for my
case, my board simply couldn't boot anymore, without any explanation. 
If there
was a message along the lines ?You are setting up IRQs starting from 0, 
which
is not supported by the kernel anymore? just before crashing, maybe it 
would
help debugging the issue.

I could try to write a patch for it, but I was first wondering if this 
is a
good idea or not.

Regards,
--
benjamin

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Fri, Jun 19, 2015 at 03:46:45PM +0200, Benjamin Cama wrote:
> Le 2015-06-19 15:13, Russell King - ARM Linux a ??crit??:
> >On Fri, Jun 19, 2015 at 02:16:34PM +0200, Benjamin Cama wrote:
...
> >>I was not talking about the irq handler, but the irq initialization
> >>routine (on orion5x, orion_irq_init calls irq_alloc_generic_chip
> >>with 0), which takes the starting irq number and may warn when it is
> >>zero (well, it may also start allocating at zero but never use it,
> >>so this may not be a totally correct assumption, but I think this
> >>comes close, and it's just a warning).
> >
> >It needs fixing nevertheless - arguments along the lines of "this
> >used to work" don't work for this topic.
> >
> >The simple answer is to adjust the initialisation to bump the IRQ
> >numbers up by one, and them adjust the interrupt numbers in
> >arch/arm/mach-whatever/include/asm/irqs.h also up by one.  That's
> >far easier to do than spending ages trying to argue against the
> >"IRQ0 is not valid" issue, only to ultimately get nowhere, and end
> >up with that as the only way forward anyway.
> 
> Do not misunderstand me: I am not at all for keeping the situation
> like this!  What I ask is just for users to be notified of this new
> requirement: for my case, my board simply couldn't boot anymore,
> without any explanation. If there was a message along the lines ???You
> are setting up IRQs starting from 0, which is not supported by the
> kernel anymore??? just before crashing, maybe it would help debugging
> the issue.
> 
> I could try to write a patch for it, but I was first wondering if this
> is a good idea or not.

Let's just get the dts patch reviewed and merged first.  Russell
actually wrote the patch to do what he's describing for mach-dove.

  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html

Although, it looks like it never got updated for submission...

  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html

thx,

Jason.

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Russell King - ARM Linux]

On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> Let's just get the dts patch reviewed and merged first.  Russell
> actually wrote the patch to do what he's describing for mach-dove.
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> 
> Although, it looks like it never got updated for submission...
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html

I do still have that patch, it's based on v4.0 though - like all my
Dove work, it only builds on the previous -final kernel release.

"Getting it out there" is really low on my priority list because of
the amount of hassle involved in trying to get anything merged (read
that as: I've basically given up trying anymore because of the amount
of back pressure from people who don't read the comments from the
previous submission, and end up making the same old comments every
time - thereby ensuring that there is little in the way of forward
progress.  No, we're not using syscon nor regmap for the PMU...)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Fri, Jun 19, 2015 at 04:48:50PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> > Let's just get the dts patch reviewed and merged first.  Russell
> > actually wrote the patch to do what he's describing for mach-dove.
> > 
> >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> > 
> > Although, it looks like it never got updated for submission...
> > 
> >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
> 
> I do still have that patch, it's based on v4.0 though - like all my
> Dove work, it only builds on the previous -final kernel release.

Benjamin, after the dts, would you mind picking up Russell's dove patch and
making a cooresponding orion5x patch?

thx,

Jason.

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le vendredi 19 juin 2015 ? 17:13 +0000, Jason Cooper a ?crit :
> On Fri, Jun 19, 2015 at 04:48:50PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> > > Let's just get the dts patch reviewed and merged first.  Russell
> > > actually wrote the patch to do what he's describing for mach-dove.
> > > 
> > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> > > 
> > > Although, it looks like it never got updated for submission...
> > > 
> > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
> > 
> > I do still have that patch, it's based on v4.0 though - like all my
> > Dove work, it only builds on the previous -final kernel release.
> 
> Benjamin, after the dts, would you mind picking up Russell's dove patch and
> making a cooresponding orion5x patch?

If the plan is to move to DT, is it still needed?

--
benjamin

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Sun, Jun 21, 2015 at 07:37:55PM +0200, Benjamin Cama wrote:
> Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
> > On Fri, Jun 19, 2015 at 04:48:50PM +0100, Russell King - ARM Linux wrote:
> > > On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> > > > Let's just get the dts patch reviewed and merged first.  Russell
> > > > actually wrote the patch to do what he's describing for mach-dove.
> > > > 
> > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> > > > 
> > > > Although, it looks like it never got updated for submission...
> > > > 
> > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
> > > 
> > > I do still have that patch, it's based on v4.0 though - like all my
> > > Dove work, it only builds on the previous -final kernel release.
> > 
> > Benjamin, after the dts, would you mind picking up Russell's dove patch and
> > making a cooresponding orion5x patch?
> 
> If the plan is to move to DT, is it still needed?

Sure, because orion5x is slow-going.  There aren't that many users.
Since we prefer tested patches, we need to grab the opportunity when it
comes a long.  It could be another year or more before we see more
patches for orion5x.  Fully converting orion5x to DT doesn't have a
schedule, it's as we encounter devs willing to post patches for their
boards.

The opportunity here is that you were just booting a legacy board file
on an orion5x SoC.  Therefore, you're in the best position to write/test
the irq change.

thx,

Jason.

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le lundi 22 juin 2015 ? 12:08 +0000, Jason Cooper a ?crit :
> On Sun, Jun 21, 2015 at 07:37:55PM +0200, Benjamin Cama wrote:
> > Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
> > > On Fri, Jun 19, 2015 at 04:48:50PM +0100, Russell King - ARM Linux wrote:
> > > > On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> > > > > Let's just get the dts patch reviewed and merged first.  Russell
> > > > > actually wrote the patch to do what he's describing for mach-dove.
> > > > > 
> > > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> > > > > 
> > > > > Although, it looks like it never got updated for submission...
> > > > > 
> > > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
> > > > 
> > > > I do still have that patch, it's based on v4.0 though - like all my
> > > > Dove work, it only builds on the previous -final kernel release.
> > > 
> > > Benjamin, after the dts, would you mind picking up Russell's dove patch and
> > > making a cooresponding orion5x patch?
> > 
> > If the plan is to move to DT, is it still needed?
> 
> Sure, because orion5x is slow-going.  There aren't that many users.
> Since we prefer tested patches, we need to grab the opportunity when it
> comes a long.  It could be another year or more before we see more
> patches for orion5x.  Fully converting orion5x to DT doesn't have a
> schedule, it's as we encounter devs willing to post patches for their
> boards.

According to rmk, letting their board break may be a quicker way to get
the patches ;-) (and I agree with that: I wouldn't have moved to DT so
fast if the build didn't break, it is a good incentive).

> The opportunity here is that you were just booting a legacy board file
> on an orion5x SoC.  Therefore, you're in the best position to write/test
> the irq change.

OK, I understand. I'll try to find the time to test the non-DT case and
offer a patch. About Russell's one: how is the Signed-off-by going in
this case? I put his and then mine?

Regards,
--
benjamin

[PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Mon, Jun 22, 2015 at 07:49:39PM +0200, Benjamin Cama wrote:
> Le lundi 22 juin 2015 ?? 12:08 +0000, Jason Cooper a ??crit :
> > On Sun, Jun 21, 2015 at 07:37:55PM +0200, Benjamin Cama wrote:
> > > Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
> > > > On Fri, Jun 19, 2015 at 04:48:50PM +0100, Russell King - ARM Linux wrote:
> > > > > On Fri, Jun 19, 2015 at 03:25:52PM +0000, Jason Cooper wrote:
> > > > > > Let's just get the dts patch reviewed and merged first.  Russell
> > > > > > actually wrote the patch to do what he's describing for mach-dove.
> > > > > > 
> > > > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
> > > > > > 
> > > > > > Although, it looks like it never got updated for submission...
> > > > > > 
> > > > > >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
> > > > > 
> > > > > I do still have that patch, it's based on v4.0 though - like all my
> > > > > Dove work, it only builds on the previous -final kernel release.
> > > > 
> > > > Benjamin, after the dts, would you mind picking up Russell's dove patch and
> > > > making a cooresponding orion5x patch?
> > > 
> > > If the plan is to move to DT, is it still needed?
> > 
> > Sure, because orion5x is slow-going.  There aren't that many users.
> > Since we prefer tested patches, we need to grab the opportunity when it
> > comes a long.  It could be another year or more before we see more
> > patches for orion5x.  Fully converting orion5x to DT doesn't have a
> > schedule, it's as we encounter devs willing to post patches for their
> > boards.
> 
> According to rmk, letting their board break may be a quicker way to get
> the patches ;-) (and I agree with that: I wouldn't have moved to DT so
> fast if the build didn't break, it is a good incentive).

Oddly enough, that's how I got roped into being a maintainer.  :-P

> > The opportunity here is that you were just booting a legacy board file
> > on an orion5x SoC.  Therefore, you're in the best position to write/test
> > the irq change.
> 
> OK, I understand. I'll try to find the time to test the non-DT case and
> offer a patch. About Russell's one: how is the Signed-off-by going in
> this case? I put his and then mine?

Well, it looks like it applies cleanly to linux-next, so we can probably
take it as is.  My request was wrt the original patch I linked to, which
would have needed a rebase.

So, no need to do anything with rmk's patch.  Just use it as a base for
the orion5x case if you need to.

thx,

Jason.

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Benjamin Cama]

Since v3.18, attempts to deviler IRQ0 are rejected, breaking orion5x.
Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for
dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including
dove) as the specific handler is needed to shift back IRQ numbers by
one.

Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq")
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
---
Hi everyone,

I finally nailed it: my attempt at copying Russell's patch for dove did
not work because MULTI_IRQ_HANDLER was not set. It is not in the
defconfig; maybe it should be now? I hesitated to put it as a
dependency for PLAT_ORION_LEGACY, but as the platform is globally
broken without it, I added it.

What do you think?

 arch/arm/Kconfig                          |  1 +
 arch/arm/mach-orion5x/include/mach/irqs.h | 64 +++++++++++++++----------------
 arch/arm/mach-orion5x/irq.c               |  4 +-
 3 files changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 45df48b..a55c63a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -968,6 +968,7 @@ config PLAT_ORION
 config PLAT_ORION_LEGACY
 	bool
 	select PLAT_ORION
+	select MULTI_IRQ_HANDLER
 
 config PLAT_PXA
 	bool
diff --git a/arch/arm/mach-orion5x/include/mach/irqs.h b/arch/arm/mach-orion5x/include/mach/irqs.h
index a6fa9d8..2431d99 100644
--- a/arch/arm/mach-orion5x/include/mach/irqs.h
+++ b/arch/arm/mach-orion5x/include/mach/irqs.h
@@ -16,42 +16,42 @@
 /*
  * Orion Main Interrupt Controller
  */
-#define IRQ_ORION5X_BRIDGE		0
-#define IRQ_ORION5X_DOORBELL_H2C	1
-#define IRQ_ORION5X_DOORBELL_C2H	2
-#define IRQ_ORION5X_UART0		3
-#define IRQ_ORION5X_UART1		4
-#define IRQ_ORION5X_I2C			5
-#define IRQ_ORION5X_GPIO_0_7		6
-#define IRQ_ORION5X_GPIO_8_15		7
-#define IRQ_ORION5X_GPIO_16_23		8
-#define IRQ_ORION5X_GPIO_24_31		9
-#define IRQ_ORION5X_PCIE0_ERR		10
-#define IRQ_ORION5X_PCIE0_INT		11
-#define IRQ_ORION5X_USB1_CTRL		12
-#define IRQ_ORION5X_DEV_BUS_ERR		14
-#define IRQ_ORION5X_PCI_ERR		15
-#define IRQ_ORION5X_USB_BR_ERR		16
-#define IRQ_ORION5X_USB0_CTRL		17
-#define IRQ_ORION5X_ETH_RX		18
-#define IRQ_ORION5X_ETH_TX		19
-#define IRQ_ORION5X_ETH_MISC		20
-#define IRQ_ORION5X_ETH_SUM		21
-#define IRQ_ORION5X_ETH_ERR		22
-#define IRQ_ORION5X_IDMA_ERR		23
-#define IRQ_ORION5X_IDMA_0		24
-#define IRQ_ORION5X_IDMA_1		25
-#define IRQ_ORION5X_IDMA_2		26
-#define IRQ_ORION5X_IDMA_3		27
-#define IRQ_ORION5X_CESA		28
-#define IRQ_ORION5X_SATA		29
-#define IRQ_ORION5X_XOR0		30
-#define IRQ_ORION5X_XOR1		31
+#define IRQ_ORION5X_BRIDGE		(1 + 0)
+#define IRQ_ORION5X_DOORBELL_H2C	(1 + 1)
+#define IRQ_ORION5X_DOORBELL_C2H	(1 + 2)
+#define IRQ_ORION5X_UART0		(1 + 3)
+#define IRQ_ORION5X_UART1		(1 + 4)
+#define IRQ_ORION5X_I2C			(1 + 5)
+#define IRQ_ORION5X_GPIO_0_7		(1 + 6)
+#define IRQ_ORION5X_GPIO_8_15		(1 + 7)
+#define IRQ_ORION5X_GPIO_16_23		(1 + 8)
+#define IRQ_ORION5X_GPIO_24_31		(1 + 9)
+#define IRQ_ORION5X_PCIE0_ERR		(1 + 10)
+#define IRQ_ORION5X_PCIE0_INT		(1 + 11)
+#define IRQ_ORION5X_USB1_CTRL		(1 + 12)
+#define IRQ_ORION5X_DEV_BUS_ERR		(1 + 14)
+#define IRQ_ORION5X_PCI_ERR		(1 + 15)
+#define IRQ_ORION5X_USB_BR_ERR		(1 + 16)
+#define IRQ_ORION5X_USB0_CTRL		(1 + 17)
+#define IRQ_ORION5X_ETH_RX		(1 + 18)
+#define IRQ_ORION5X_ETH_TX		(1 + 19)
+#define IRQ_ORION5X_ETH_MISC		(1 + 20)
+#define IRQ_ORION5X_ETH_SUM		(1 + 21)
+#define IRQ_ORION5X_ETH_ERR		(1 + 22)
+#define IRQ_ORION5X_IDMA_ERR		(1 + 23)
+#define IRQ_ORION5X_IDMA_0		(1 + 24)
+#define IRQ_ORION5X_IDMA_1		(1 + 25)
+#define IRQ_ORION5X_IDMA_2		(1 + 26)
+#define IRQ_ORION5X_IDMA_3		(1 + 27)
+#define IRQ_ORION5X_CESA		(1 + 28)
+#define IRQ_ORION5X_SATA		(1 + 29)
+#define IRQ_ORION5X_XOR0		(1 + 30)
+#define IRQ_ORION5X_XOR1		(1 + 31)
 
 /*
  * Orion General Purpose Pins
  */
-#define IRQ_ORION5X_GPIO_START	32
+#define IRQ_ORION5X_GPIO_START	33
 #define NR_GPIO_IRQS		32
 
 #define NR_IRQS			(IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS)
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index cd4bac4..086ecb8 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -42,7 +42,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)
 	stat = readl_relaxed(MAIN_IRQ_CAUSE);
 	stat &= readl_relaxed(MAIN_IRQ_MASK);
 	if (stat) {
-		unsigned int hwirq = __fls(stat);
+		unsigned int hwirq = 1 + __fls(stat);
 		handle_IRQ(hwirq, regs);
 		return;
 	}
@@ -51,7 +51,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)
 
 void __init orion5x_init_irq(void)
 {
-	orion_irq_init(0, MAIN_IRQ_MASK);
+	orion_irq_init(1, MAIN_IRQ_MASK);
 
 #ifdef CONFIG_MULTI_IRQ_HANDLER
 	set_handle_irq(orion5x_legacy_handle_irq);
-- 
2.1.4

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Arnd Bergmann]

On Tuesday 14 July 2015 16:25:58 Benjamin Cama wrote:
> Hi everyone,
> 
> I finally nailed it: my attempt at copying Russell's patch for dove did
> not work because MULTI_IRQ_HANDLER was not set. It is not in the
> defconfig; maybe it should be now? I hesitated to put it as a
> dependency for PLAT_ORION_LEGACY, but as the platform is globally
> broken without it, I added it.
> 
> What do you think?
> 

I think it makes sense the way you did here.

See also my patch at

http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/commit/?h=multiplatform-4.2-next&id=44b55cab3bd74739e4c39205d41e1b2ed8953155

I'd be happy if we could just merge that one, along with the other
plat-orion multiplatform patches at
http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=b1f5b2f1a738d7f78b94856bfe7a1a7d4da1fbd1

I did not manage to get them merged before my parental leave and
certainly won't be able to do it before I get back to work, but maybe
someone else can have a look. I think the five patches should all
be fine there, they mainly need testing on real hardware.

	Arnd

[PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers

[Gregory CLEMENT]

Hi Arnd, Benjamin,

On 14/07/2015 22:50, Arnd Bergmann wrote:
> On Tuesday 14 July 2015 16:25:58 Benjamin Cama wrote:
>> Hi everyone,
>>
>> I finally nailed it: my attempt at copying Russell's patch for dove did
>> not work because MULTI_IRQ_HANDLER was not set. It is not in the
>> defconfig; maybe it should be now? I hesitated to put it as a
>> dependency for PLAT_ORION_LEGACY, but as the platform is globally
>> broken without it, I added it.
>>
>> What do you think?
>>
> 
> I think it makes sense the way you did here.
> 
> See also my patch at
> 
> http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/commit/?h=multiplatform-4.2-next&id=44b55cab3bd74739e4c39205d41e1b2ed8953155
> 
> I'd be happy if we could just merge that one, along with the other
> plat-orion multiplatform patches at
> http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=b1f5b2f1a738d7f78b94856bfe7a1a7d4da1fbd1
> 
> I did not manage to get them merged before my parental leave and
> certainly won't be able to do it before I get back to work, but maybe
> someone else can have a look. I think the five patches should all
> be fine there, they mainly need testing on real hardware.

Benjamin's patch definitely needs to be applied, as another orion user got
an issue too:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364503.html


The remaining question in this thread was about only taking Benjamin patch
or the full series from Arnd. But now it is too late to take the full series
and currently there is a bug in 4.2-rc. So first I will apply this patch with
the hope that it could be merged before the 4.2 release.

Later we definitely will need to take care of Arnd series.

Thanks,

Gregory

> 
> 	Arnd
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com