Linkstation Mini and __machine_arch_type problem, not booting since 3.8

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Hi everyone,

First, I am new here (and not subscribed, so Cc me please). I hope I am
on the right list [edit: resent to the correct one, again].

I usually run old kernels (3.2) on my Linkstation Mini
(CONFIG_MACH_LINKSTATION_MINI, Marvell Orion based, non-DT) but I 
wanted
to try a newer one and found that after 3.7, it didn't boot anymore at
all: no message at all displayed, not even with earlyprintk. I bisected
the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878 
?ARM:
7602/1: Pass real "__machine_arch_type" variable to 
setup_machine_tags()
procedure? which looks like a quite broad change, and makes me 1) not
really understand what it does 2) astonished not to see someone else
affected (judging by the time since it doesn't work). Using the version
prior to this commit works, but trying to revert it on some newer
version (4.1-rc7) also fails, so the change must be something deeper
that I can handle. Note that when I disable CONFIG_CPU_FEROCEON_OLD_ID
(it is such an old Feroceon), it still correctly displays at boot
?Error: unrecognized/unsupported processor variant (0x41069260).?, so
the machine ID is somewhat read correctly.

Also, my intent at first was to try converting this machine to DT, so 
maybe
the solution to my problem would simply be to try converting it and see
if it fixes the problem?

Thanks for any thought on this problem,
--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Hi,

Le lundi 15 juin 2015 ? 15:51 +0200, Benjamin Cama a ?crit :
> it didn't boot anymore at
> all: no message at all displayed, not even with earlyprintk

Note that I tried the earlyprintk=serial,ttyS0,115200 with a working
kernel as I do for the non-working ones, and it hangs at boot too, so
this is no indication, sorry.

> I bisected
> the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878 
> ?ARM:
> 7602/1: Pass real "__machine_arch_type" variable to 
> setup_machine_tags()
> procedure? which looks like a quite broad change, and makes me 1) not
> really understand what it does 2) astonished not to see someone else
> affected (judging by the time since it doesn't work).

I dug some more and found what changed: it simply passes the bootloader
-provided machine ID instead of the kernel-configured one! This is
quite a change indeed, which is not mentionned in the commit text. This
may seem good for vendor-provided support which assigns IDs early with
upstream, but for user one (like for this machine), the machine ID will
in general be some ID that has nothing to do with the one passed by the
bootloader. So this ought to be mentioned somewhere!

How I found this? Well, my bootloader passes a bad machine ID (526
instead of 1858), and thus the code doesn't recognize it. What I cannot
understand is why the decompressor doesn't even run with a wrong
machine ID (MMU initialization that depend on it maybe??). This is very
strange.

And also, I don't get why a more recent kernel with a hardcoded machine
ID (personal modification) doesn't work either. Maybe I should bisect
that too.

> Using the version
> prior to this commit works, but trying to revert it on some newer
> version (4.1-rc7) also fails, so the change must be something deeper
> that I can handle. Note that when I disable 
> CONFIG_CPU_FEROCEON_OLD_ID
> (it is such an old Feroceon), it still correctly displays at boot
> ?Error: unrecognized/unsupported processor variant (0x41069260).?, so
> the machine ID is somewhat read correctly.

Note about my confusion: this is the processor ID, not the machine ID.

Thanks for any help again,
--
benjamin

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

[Benjamin Cama]

Hi again (feeling lonely),

I have got some news, I think I found the culprit.

Le mardi 16 juin 2015 ? 11:20 +0200, Benjamin Cama a ?crit :
> Le lundi 15 juin 2015 ? 15:51 +0200, Benjamin Cama a ?crit :
> > it didn't boot anymore at
> > all: no message at all displayed, not even with earlyprintk
> 
> Note that I tried the earlyprintk=serial,ttyS0,115200 with a working
> kernel as I do for the non-working ones, and it hangs at boot too, so
> this is no indication, sorry.

(Note for later: read the manual first, earlyprintk on this arch is for
a special tool to handle on the serial port on the host side. So it
looks like it hangs when running with it.)

> > I bisected
> > the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878 
> > ?ARM:
> > 7602/1: Pass real "__machine_arch_type" variable to 
> > setup_machine_tags()
> > procedure? which looks like a quite broad change, and makes me 1) 
> > not
> > really understand what it does 2) astonished not to see someone 
> > else
> > affected (judging by the time since it doesn't work).
> 
> I dug some more and found what changed: it simply passes the bootloader
> -provided machine ID instead of the kernel-configured one! This is
> quite a change indeed, which is not mentionned in the commit text. This
> may seem good for vendor-provided support which assigns IDs early with
> upstream, but for user one (like for this machine), the machine ID will
> in general be some ID that has nothing to do with the one passed by the
> bootloader. So this ought to be mentioned somewhere!

No comment on this? I continued with my hack which hardcodes the
machine ID, but has anyone some advice on how it should be done? Should
the behavior be reverted, or is there a clean way to force a machine ID
at build time?

> How I found this? Well, my bootloader passes a bad machine ID (526
> instead of 1858), and thus the code doesn't recognize it. What I cannot
> understand is why the decompressor doesn't even run with a wrong
> machine ID (MMU initialization that depend on it maybe??). This is very
> strange.

(that was because I enabled earlyprintk, which for some reason removes
messages from the decompressor? or maybe I mixed things up while
configuring the kernel)

> And also, I don't get why a more recent kernel with a hardcoded machine
> ID (personal modification) doesn't work either. Maybe I should bisect
> that too.

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 {
-- 
2.1.4

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

[Marc Zyngier]

Hi Benjamin,

On 18/06/15 03:12, Benjamin Cama wrote:
> Hi again (feeling lonely),

[...]

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

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.

Looking forward to reviewing your patches,

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

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

[Arnd Bergmann]

On Thursday 18 June 2015 08:52:08 Marc Zyngier wrote:
> 
> On 18/06/15 03:12, Benjamin Cama wrote:
> 
> 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.
> 
> 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.
> 
> Looking forward to reviewing your patches,

Converting to DT should indeed solve the problem, as that uses
a more modern irqchip driver that does not use IRQ0.

Thomas Petazzoni has worked on converting orion5x machines to DT
in the past, I've cc'd him and the mvebu maintainers here, they
should be able to comment on what is actually required to do the
conversion. It's possible that all drivers you need have already
been converted and you just need to add a new dts files similar to
the other arch/arm/boot/dts/orion5x-*.dts files and can remove
that other board file.

	Arnd

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

[Andrew Lunn]

> Thomas Petazzoni has worked on converting orion5x machines to DT
> in the past, I've cc'd him and the mvebu maintainers here, they
> should be able to comment on what is actually required to do the
> conversion. It's possible that all drivers you need have already
> been converted and you just need to add a new dts files similar to
> the other arch/arm/boot/dts/orion5x-*.dts files and can remove
> that other board file.

I had a quick look at lsmini-setup.c. Everything it uses is DT ready,
so the conversion should be painless.

   Andrew

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

[Benjamin Cama]

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.

> 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??

> Looking forward to reviewing your patches,

Thanks for your help and support. As the others suggested (thanks to
all of you too), I will try the DT way directly then.

Regards,
--
benjamin

[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

[Jason Cooper]

Benjamin,

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:
...
> > > 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?

If folks are using the sub-arch and interested in maintaining them, they
stick around.  mach-orion5x/ is a wierd case because there aren't many
users.  The mvebu folks have put a lot of work into supporting /
converting the legacy platforms (kirkwood, dove).  Thomas did most of
the work converting orion5x, but there simply aren't many users to test.
So it's in a half-converted state.

iow, we're glad to see you contributing patches for orion5x.  ;-)

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

[Russell King - ARM Linux]

On Mon, Jun 22, 2015 at 07:49:39PM +0200, Benjamin Cama wrote:
> 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?

If you produce an entirely separate patch to address Orion5x in the same
way that I've done with Dove, then there's no reason to have my sign-off
on it, because none of it will contain work that I've done.

Also note that I've actually re-sent that patch today, and Andrew says
he'll apply it around -rc1 time, so you don't have to include the Dove
bits in your patch.

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

[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:46:45PM +0200, Benjamin Cama wrote:
> Hi Russell,
> 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.

It's not a new requirement.  It's something that's been there all along,
and is finally starting to bite places where it never used to bite before.
It's a latent bug in platform code, that's all.

This "IRQ0 is bad" has been known for quite some while - you've already
been pointed at Linus' rant about it, dated 25 Jan 2007.  If you do a bit
of research, you'll find that the orion code was contributed _after_ that
date.

While it's easy to stick a warning into orion_irq_init() (or whatever the
function is called), it's utterly pointless now that it's been found -
just fix all the users of orion_irq_init() now and be done with it.

As for "shouldn't this have had a warning in the past", well, maybe, but
consider this task:

	Please go and look at the other mach-* directories, and find
	all those which might use IRQ0, and arrange for them to print
	a warning.

I'm sure you'll see what a task it is that you're asking for.

What you're asking for is actually unreasonable.


(I am aware that Dove broke exactly for this reason, and I've been
carrying a patch since December 2014 to fix Dove - but I just don't have
the time to get it merged - like most of my other Dove work.)

-- 
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]

Le vendredi 19 juin 2015 ? 16:44 +0100, Russell King - ARM Linux a
?crit :
> On Fri, Jun 19, 2015 at 03:46:45PM +0200, Benjamin Cama wrote:
> > Hi Russell,
> > 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.
> 
> It's not a new requirement.  It's something that's been there all along,
> and is finally starting to bite places where it never used to bite before.
> It's a latent bug in platform code, that's all.
> 
> This "IRQ0 is bad" has been known for quite some while - you've already
> been pointed at Linus' rant about it, dated 25 Jan 2007.  If you do a bit
> of research, you'll find that the orion code was contributed _after_ that
> date.

Yes, I understand.

> While it's easy to stick a warning into orion_irq_init() (or whatever the
> function is called), it's utterly pointless now that it's been found -
> just fix all the users of orion_irq_init() now and be done with it.

Well, I could do that but I do not have all the hardware to test it on.

> As for "shouldn't this have had a warning in the past", well, maybe, but
> consider this task:
> 
> 	> Please go and look at the other mach-* directories, and find
> 	> all those which might use IRQ0, and arrange for them to print
> 	> a warning.
> 
> I'm sure you'll see what a task it is that you're asking for.
> 
> What you're asking for is actually unreasonable.

I was not at all asking for that, sorry for the misunderstanding again:
I was imagining putting a warning or BUG_ON in e.g.
irq_alloc_generic_chip (and just one place; I am not even sure this is
the right one: I am quite a beginner in kernel code, to put things in
context). I tried that but with bad results (just a hard reboot for
BUG_ON without message) maybe because without earlyprintk, it happens
too early in the boot process to display anything to the user. So this
is a bad idea indeed.

> (I am aware that Dove broke exactly for this reason, and I've been
> carrying a patch since December 2014 to fix Dove - but I just don't have
> the time to get it merged - like most of my other Dove work.)

I tried a quick grep'ing of platforms allocating IRQ0, and all Orion is
indeed doing it, as well as davinci. But apart from them, the rest
seems OK, so the platforms having this problem seem indeed to be very
few.

Regards,
--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Gregory CLEMENT]

Hi Benjamin,



On 15/06/2015 15:51, Benjamin Cama wrote:
> Hi everyone,
> 
> First, I am new here (and not subscribed, so Cc me please). I hope I am
> on the right list [edit: resent to the correct one, again].
> 
> I usually run old kernels (3.2) on my Linkstation Mini
> (CONFIG_MACH_LINKSTATION_MINI, Marvell Orion based, non-DT) but I 
> wanted
> to try a newer one and found that after 3.7, it didn't boot anymore at
> all: no message at all displayed, not even with earlyprintk. I bisected
> the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878 
> ?ARM:
> 7602/1: Pass real "__machine_arch_type" variable to 
> setup_machine_tags()
> procedure? which looks like a quite broad change, and makes me 1) not
> really understand what it does 2) astonished not to see someone else
> affected (judging by the time since it doesn't work). Using the version
> prior to this commit works, but trying to revert it on some newer
> version (4.1-rc7) also fails, so the change must be something deeper
> that I can handle. Note that when I disable CONFIG_CPU_FEROCEON_OLD_ID
> (it is such an old Feroceon), it still correctly displays at boot
> ?Error: unrecognized/unsupported processor variant (0x41069260).?, so
> the machine ID is somewhat read correctly.
> 
> Also, my intent at first was to try converting this machine to DT, so 
> maybe
> the solution to my problem would simply be to try converting it and see
> if it fixes the problem?

Indeed it is your best option given the problem you exposed later in this
thread. Our plan in mid-term is to completely remove the non-DT support.
So converting the board is definitely the right thing to do.

The conversation should not be too hard to achieve, you will have mainly to
write a dts, build a dtb an append it to your kernel.
You can have a look on waht was done for the LaCie d2 Network platform, see
94b0bd366e36379c994bdaa84f 'ARM: orion5x: convert d2net to Device Tree'


If you have any trouble or question during the conversion we will help you.


Thanks,

Gregory



> 
> Thanks for any thought on this problem,
> --
> benjamin
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


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

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Hi Gr?gory, Andrew and Arnd,

Le jeudi 18 juin 2015 ? 10:12 +0200, Gregory CLEMENT a ?crit :
> On 15/06/2015 15:51, Benjamin Cama wrote:
> > Also, my intent at first was to try converting this machine to DT, so 
> > maybe
> > the solution to my problem would simply be to try converting it and see
> > if it fixes the problem?
> 
> Indeed it is your best option given the problem you exposed later in this
> thread. Our plan in mid-term is to completely remove the non-DT support.
> So converting the board is definitely the right thing to do.
> 
> The conversation should not be too hard to achieve, you will have mainly to
> write a dts, build a dtb an append it to your kernel.
> You can have a look on waht was done for the LaCie d2 Network platform, see
> 94b0bd366e36379c994bdaa84f 'ARM: orion5x: convert d2net to Device Tree'

OK, I tried following you advice, and copied step by step the dts with
values corresponding to my board.

> If you have any trouble or question during the conversion we will 
> help you.

It took several iterations to get done, but attached is the dts I
wrote. Still, it doesn't boot and I get no message after the
decompressor message. But I get something: the leds change according to
the configuration of the dts, so something is going on (I noticed the
change after several failed boot where no led changed and fixing a typo
made it).

My main problem is getting some debug messages: no amount of "debug"
and "loglevel" on the command line seems to change anything. Is it too
early in the boot process to get anything output or am I doing
something wrong? (I activated some configs for debugging, but I may
have missed the good one)

Thanks,
--
benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orion5x-ls-wsgl.dts
Type: audio/vnd.dts
Size: 4026 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150619/cb40848b/attachment-0001.dts>

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Gregory CLEMENT]

Hi Benjamin,

On 19/06/2015 03:50, Benjamin Cama wrote:
> Hi Gr?gory, Andrew and Arnd,
> 
> Le jeudi 18 juin 2015 ? 10:12 +0200, Gregory CLEMENT a ?crit :
>> On 15/06/2015 15:51, Benjamin Cama wrote:
>>> Also, my intent at first was to try converting this machine to DT, so 
>>> maybe
>>> the solution to my problem would simply be to try converting it and see
>>> if it fixes the problem?
>>
>> Indeed it is your best option given the problem you exposed later in this
>> thread. Our plan in mid-term is to completely remove the non-DT support.
>> So converting the board is definitely the right thing to do.
>>
>> The conversation should not be too hard to achieve, you will have mainly to
>> write a dts, build a dtb an append it to your kernel.
>> You can have a look on waht was done for the LaCie d2 Network platform, see
>> 94b0bd366e36379c994bdaa84f 'ARM: orion5x: convert d2net to Device Tree'
> 
> OK, I tried following you advice, and copied step by step the dts with
> values corresponding to my board.
> 
>> If you have any trouble or question during the conversion we will 
>> help you.
> 
> It took several iterations to get done, but attached is the dts I
> wrote. Still, it doesn't boot and I get no message after the
> decompressor message. But I get something: the leds change according to
> the configuration of the dts, so something is going on (I noticed the
> change after several failed boot where no led changed and fixing a typo
> made it).
> 
> My main problem is getting some debug messages: no amount of "debug"
> and "loglevel" on the command line seems to change anything. Is it too
> early in the boot process to get anything output or am I doing
> something wrong? (I activated some configs for debugging, but I may
> have missed the good one)

Try to activate earlyprintk. For this you have to select CONFIG_EARLY_PRINTK
which depend on DEBUG_LL. You will also have to add the argument
"earlyprintk" to your kernel parameters.

Gregory


> 
> Thanks,
> --
> benjamin
> 


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

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Fri, Jun 19, 2015 at 11:33:13AM +0200, Gregory CLEMENT wrote:
> Hi Benjamin,
> 
> On 19/06/2015 03:50, Benjamin Cama wrote:
> > Hi Gr??gory, Andrew and Arnd,
> > 
> > Le jeudi 18 juin 2015 ?? 10:12 +0200, Gregory CLEMENT a ??crit :
> >> On 15/06/2015 15:51, Benjamin Cama wrote:
> >>> Also, my intent at first was to try converting this machine to DT, so 
> >>> maybe
> >>> the solution to my problem would simply be to try converting it and see
> >>> if it fixes the problem?
> >>
> >> Indeed it is your best option given the problem you exposed later in this
> >> thread. Our plan in mid-term is to completely remove the non-DT support.
> >> So converting the board is definitely the right thing to do.
> >>
> >> The conversation should not be too hard to achieve, you will have mainly to
> >> write a dts, build a dtb an append it to your kernel.
> >> You can have a look on waht was done for the LaCie d2 Network platform, see
> >> 94b0bd366e36379c994bdaa84f 'ARM: orion5x: convert d2net to Device Tree'
> > 
> > OK, I tried following you advice, and copied step by step the dts with
> > values corresponding to my board.
> > 
> >> If you have any trouble or question during the conversion we will 
> >> help you.
> > 
> > It took several iterations to get done, but attached is the dts I
> > wrote. Still, it doesn't boot and I get no message after the
> > decompressor message. But I get something: the leds change according to
> > the configuration of the dts, so something is going on (I noticed the
> > change after several failed boot where no led changed and fixing a typo
> > made it).
> > 
> > My main problem is getting some debug messages: no amount of "debug"
> > and "loglevel" on the command line seems to change anything. Is it too
> > early in the boot process to get anything output or am I doing
> > something wrong? (I activated some configs for debugging, but I may
> > have missed the good one)
> 
> Try to activate earlyprintk. For this you have to select CONFIG_EARLY_PRINTK
> which depend on DEBUG_LL. You will also have to add the argument
> "earlyprintk" to your kernel parameters.

SERIAL_OF_PLATFORM?

thx,

Jason.

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le vendredi 19 juin 2015 ? 11:41 +0000, Jason Cooper a ?crit :
> On Fri, Jun 19, 2015 at 11:33:13AM +0200, Gregory CLEMENT wrote:
> > On 19/06/2015 03:50, Benjamin Cama wrote:
> > > My main problem is getting some debug messages: no amount of "debug"
> > > and "loglevel" on the command line seems to change anything. Is it too
> > > early in the boot process to get anything output or am I doing
> > > something wrong? (I activated some configs for debugging, but I may
> > > have missed the good one)
> > 
> > Try to activate earlyprintk. For this you have to select CONFIG_EARLY_PRINTK
> > which depend on DEBUG_LL. You will also have to add the argument
> > "earlyprintk" to your kernel parameters.

Yes, this is what I tried before without success, but then I looked
again and realized? that I missed the option to choose the correct
output just below the ?Kernel low-level debugging functions? option
because the text line was too long and I didn't see it chose
?EmbeddedICE DCC channel? by default instead of the UART. Big fail for
me here.

Still, no output.

> SERIAL_OF_PLATFORM?

Oh, and that was it! Why isn't it selected by the DT config? I see that
it's in the defconfigs, but selected nowhere by any option. Is there a
particular reason for this?

Then I saw the kernel log, I witnessed that it worked well, it just
couldn't find a root fs (I was booting with dummy parameters). So the
DT I made is actually working!

Thanks for your help, the patch will be following,
--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Andrew Lunn]

> > SERIAL_OF_PLATFORM?
> 
> Oh, and that was it!

This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be
accepted.

	Andrew

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le samedi 20 juin 2015 ? 16:36 +0200, Andrew Lunn a ?crit :
> > 
> > > SERIAL_OF_PLATFORM?
> > 
> > Oh, and that was it!
> 
> This used to catch us all out a lot. What configuration are you using?
> orion5x_defconfig? Very likely a patch adding it to that would be
> accepted.

None. Sorry, I am used to the x86 world where I almost never used
default configs (and it's been a long time, too). I admit I never fully
understood the logic behind the defconfigs, apart from it meaning some
kind of ?less important? dependency on some specific options. Shouldn't
the main UART be a ?hard? dependency on every board?!

--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Andrew Lunn]

On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> Le samedi 20 juin 2015 ? 16:36 +0200, Andrew Lunn a ?crit :
> > > 
> > > > SERIAL_OF_PLATFORM?
> > > 
> > > Oh, and that was it!
> > 
> > This used to catch us all out a lot. What configuration are you using?
> > orion5x_defconfig? Very likely a patch adding it to that would be
> > accepted.
> 
> None. Sorry, I am used to the x86 world where I almost never used
> default configs (and it's been a long time, too). I admit I never fully
> understood the logic behind the defconfigs, apart from it meaning some
> kind of ???less important??? dependency on some specific options. Shouldn't
> the main UART be a ???hard??? dependency on every board?!

You say you are from the x86 world. When did you last use a serial
console on an x86? Anyway, the thinking at the time was that for most
NAS boxes, there is no DB-9 on the back. You have to open up the case,
and connect to a header, or even solder wires to the board, in order
to use a TTL-Serial converter. Very few people actually do that, so
why make the kernel a bit bigger?

But we have moved on since then, mostly because we ourselves have
forgotten this option too many times. We have SERIAL_OF_PLATFORM
enabled in the _defconfig.

	  Andrew

SERIAL_OF_PLATFORM default setting for DT headless systems

[Jason Cooper]

On Mon, Jun 22, 2015 at 07:43:20PM +0200, Benjamin Cama wrote:
> Le dimanche 21 juin 2015 ?? 22:07 +0200, Andrew Lunn a ??crit :
> > On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> > > Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
> > > > > 
> > > > > > SERIAL_OF_PLATFORM?
> > > > > 
> > > > > Oh, and that was it!
> > > > 
> > > > This used to catch us all out a lot. What configuration are you using?
> > > > orion5x_defconfig? Very likely a patch adding it to that would be
> > > > accepted.
> > > 
> > > None. Sorry, I am used to the x86 world where I almost never used
> > > default configs (and it's been a long time, too). I admit I never fully
> > > understood the logic behind the defconfigs, apart from it meaning some
> > > kind of ???less important??? dependency on some specific options. Shouldn't
> > > the main UART be a ???hard??? dependency on every board?!
> > 
> > You say you are from the x86 world. When did you last use a serial
> > console on an x86?
> 
> Almost daily on my headless VMs ;-) But more seriously, yes, this is
> very uncommon today. But on x86 you have virtual terminals on your
> graphic output; NAS boxes don't have them (well, maybe some high-end
> model, but it is uncommon).
> 
> > Anyway, the thinking at the time was that for most
> > NAS boxes, there is no DB-9 on the back. You have to open up the case,
> > and connect to a header, or even solder wires to the board, in order
> > to use a TTL-Serial converter. Very few people actually do that, so
> > why make the kernel a bit bigger?
> 
> Is this really a size problem? Because having a serial port on a
> *headless* machine is the most useful thing I can think of. So, to me,
> this option should definitely be activated on headless systems by
> default, even if the kernel grows a bit because of it. But I agree that
> it is useless without some advanced access to the serial port, which is
> not very common. OTOH, I think only people who have such access run non
> -stock kernels (i.e. the very one we are integrating right here,
> because vendors don't care after they shipped their device).
> 
> > But we have moved on since then, mostly because we ourselves have
> > forgotten this option too many times. We have SERIAL_OF_PLATFORM
> > enabled in the _defconfig.
> 
> That is nice to have it in the defconfig, thanks for that. But I really
> think one should consider again having some dependency on it for some
> headless platforms. I would really like to have other arguments against
> my view apart from size problems.

Well, it really comes down to the roles for Kconfig vice defconfigs.  If
we say a driver or a board 'selects' or 'depends' on something, then we
are saying either "The build will break without it", or "The board will
fail to boot without it".  Neither is true for SERIAL_OF_PLATFORM.

The defconfigs have a much looser accepted definition of "a generally
minimal, but useful set of features for an SoC, platform or
multi-platform".

Since the Kconfigs make something a hard requirement for *all* users, we
try to avoid setting those unless necessary.  I know I can't predict all
the various usecases for an arm kernel, so we try to avoid forcing
decisions on users.

The defconfigs fill the gap nicely because a user can start with a
defconfig, then enable/disable features according to their specific
use-case.

As for arguments other than size (which I think is a good one, but
still), I like security posture.  I have implemented several systems,
where the design criteria was to remove everything not actually in use.
The serial port driver was one of many features removed from the system.
The physical serial port remained if we needed to run the debug image on
a board.  If SERIAL_OF_PLATFORM was a depend, then I would have had to
carry yet another patch outside of mainline.

thx,

Jason.

SERIAL_OF_PLATFORM default setting for DT headless systems

[Benjamin Cama]

Le lundi 22 juin 2015 ? 18:23 +0000, Jason Cooper a ?crit :
> On Mon, Jun 22, 2015 at 07:43:20PM +0200, Benjamin Cama wrote:
> > Le dimanche 21 juin 2015 ?? 22:07 +0200, Andrew Lunn a ??crit :
> > > On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> > > > Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
> > > > > > 
> > > > > > > SERIAL_OF_PLATFORM?
> > > > > > 
> > > > > > Oh, and that was it!
> > > > > 
> > > > > This used to catch us all out a lot. What configuration are you using?
> > > > > orion5x_defconfig? Very likely a patch adding it to that would be
> > > > > accepted.
> > > > 
> > > > None. Sorry, I am used to the x86 world where I almost never used
> > > > default configs (and it's been a long time, too). I admit I never fully
> > > > understood the logic behind the defconfigs, apart from it meaning some
> > > > kind of ???less important??? dependency on some specific options. Shouldn't
> > > > the main UART be a ???hard??? dependency on every board?!
> > > 
> > > You say you are from the x86 world. When did you last use a serial
> > > console on an x86?
> > 
> > Almost daily on my headless VMs ;-) But more seriously, yes, this is
> > very uncommon today. But on x86 you have virtual terminals on your
> > graphic output; NAS boxes don't have them (well, maybe some high-end
> > model, but it is uncommon).
> > 
> > > Anyway, the thinking at the time was that for most
> > > NAS boxes, there is no DB-9 on the back. You have to open up the case,
> > > and connect to a header, or even solder wires to the board, in order
> > > to use a TTL-Serial converter. Very few people actually do that, so
> > > why make the kernel a bit bigger?
> > 
> > Is this really a size problem? Because having a serial port on a
> > *headless* machine is the most useful thing I can think of. So, to me,
> > this option should definitely be activated on headless systems by
> > default, even if the kernel grows a bit because of it. But I agree that
> > it is useless without some advanced access to the serial port, which is
> > not very common. OTOH, I think only people who have such access run non
> > -stock kernels (i.e. the very one we are integrating right here,
> > because vendors don't care after they shipped their device).
> > 
> > > But we have moved on since then, mostly because we ourselves have
> > > forgotten this option too many times. We have SERIAL_OF_PLATFORM
> > > enabled in the _defconfig.
> > 
> > That is nice to have it in the defconfig, thanks for that. But I really
> > think one should consider again having some dependency on it for some
> > headless platforms. I would really like to have other arguments against
> > my view apart from size problems.
> 
> Well, it really comes down to the roles for Kconfig vice defconfigs.  If
> we say a driver or a board 'selects' or 'depends' on something, then we
> are saying either "The build will break without it", or "The board will
> fail to boot without it".  Neither is true for SERIAL_OF_PLATFORM.

OK, I get that.

> The defconfigs have a much looser accepted definition of "a generally
> minimal, but useful set of features for an SoC, platform or
> multi-platform".

OK. That is the difference I was trying to understand when talking
about ?hard? or ?less important? dependency. Now I understand what are
the Kconfigs about: just the minimal stuff.

> Since the Kconfigs make something a hard requirement for *all* users, we
> try to avoid setting those unless necessary.  I know I can't predict all
> the various usecases for an arm kernel, so we try to avoid forcing
> decisions on users.
>
> The defconfigs fill the gap nicely because a user can start with a
> defconfig, then enable/disable features according to their specific
> use-case.

OK, I get the idea of their use. The assumption I had about defconfig
was right, but I didn't know the Kconfig was the absolute minimal
stuff; I thought it was maybe some ?good default without too much
cruft?, but I was wrong.

> As for arguments other than size (which I think is a good one, but
> still), I like security posture.  I have implemented several systems,
> where the design criteria was to remove everything not actually in use.
> The serial port driver was one of many features removed from the system.
> The physical serial port remained if we needed to run the debug image on
> a board.  If SERIAL_OF_PLATFORM was a depend, then I would have had to
> carry yet another patch outside of mainline.

Thanks for pointing that out, too, I hadn't think of it. And sorry if I
sounded too assertive.

Thanks again for the very good explanation,
--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Jason Cooper]

On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
> > > 
> > > > SERIAL_OF_PLATFORM?
> > > 
> > > Oh, and that was it!
> > 
> > This used to catch us all out a lot. What configuration are you using?
> > orion5x_defconfig? Very likely a patch adding it to that would be
> > accepted.
> 
> None. Sorry, I am used to the x86 world where I almost never used
> default configs (and it's been a long time, too). I admit I never fully
> understood the logic behind the defconfigs, apart from it meaning some
> kind of ???less important??? dependency on some specific options.

The defconfigs are very useful in arm-soc.  There are so many board
variations and combinations of drivers, that the defconfigs provide a
sane starting point while keeping build times down.

Several arm maintainers have boot farms that are continuously boot
testing kernels on a variety of boards.  In addition, most of the arm
kernel developers work from the defconfigs as a base.  Which means, most
of the time, the defconfig will at least boot for a given board.

thx,

Jason.

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Benjamin Cama]

Le lundi 22 juin 2015 ? 12:00 +0000, Jason Cooper a ?crit :
> On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> > Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
> > > > 
> > > > > SERIAL_OF_PLATFORM?
> > > > 
> > > > Oh, and that was it!
> > > 
> > > This used to catch us all out a lot. What configuration are you using?
> > > orion5x_defconfig? Very likely a patch adding it to that would be
> > > accepted.
> > 
> > None. Sorry, I am used to the x86 world where I almost never used
> > default configs (and it's been a long time, too). I admit I never fully
> > understood the logic behind the defconfigs, apart from it meaning some
> > kind of ???less important??? dependency on some specific options.
> 
> The defconfigs are very useful in arm-soc.  There are so many board
> variations and combinations of drivers, that the defconfigs provide a
> sane starting point while keeping build times down.
> 
> Several arm maintainers have boot farms that are continuously boot
> testing kernels on a variety of boards.  In addition, most of the arm
> kernel developers work from the defconfigs as a base.  Which means, most
> of the time, the defconfig will at least boot for a given board.

OK, thanks for the explanation, I can understand the need.

Anyway, I still think making SERIAL_OF_PLATFORM selected on headless
systems a good idea; see my other thread.

Regards,
--
benjamin

Linkstation Mini and __machine_arch_type problem, not booting since 3.8

[Andrew Lunn]

/dts-v1/;

/* TODO: the specific power off method */

You can achieve this using the restart-poweroff driver. See the
kirkwood linkstation DTS files for an example.

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include "orion5x-mv88f5182.dtsi"

/ {
	model = "Buffalo Linkstation Mini (LS-WSGL)";
	compatible = "buffalo,linkstation_mini", "marvell,orion5x-88f5182", "marvell,orion5x";

	memory {
		reg = <0x00000000 0x8000000>; /* 128 MB */
	};

	chosen {
		bootargs = "console=ttyS0,115200";
		linux,stdout-path = &uart0;
	};

	soc {
		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
			 <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
			 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
	};

	gpio-keys {
		compatible = "gpio-keys";
		pinctrl-0 = <&pmx_buttons>;
		pinctrl-names = "default";
		#address-cells = <1>;
		#size-cells = <0>;
		func {
			label = "Function Button";
			linux,code = <KEY_OPTION>;
			gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
		};

		power {
			label = "Power-on Switch";
			linux,input-type = <5>; /* EV_SW */
			linux,code = <0>; /* LSMINI_SW_POWER */
			gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
		};

		autopower {
			label = "Power-auto Switch";
			linux,input-type = <5>; /* EV_SW */
			linux,code = <1>; /* LSMINI_SW_AUTOPOWER */
			gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
		};

There is a contribute for two other linkstation devices also made
today, which have these two same buttons. I'm not sure these are the
best choice of keys, but what every we decide, we should use the same
for all linkstation devices.

	};

	gpio-leds {
		compatible = "gpio-leds";
		pinctrl-0 = <&pmx_leds>;
		pinctrl-names = "default";

		alarm {
			label = "alarm:red";

The board name should be in here. "lswsgl:alarm:red". Same for all the
LEDs.

			gpio = <&gpio0 2 GPIO_ACTIVE_LOW>;
		};

		info {
			label = "info:amber";
			gpio = <&gpio0 3 GPIO_ACTIVE_LOW>;
		};

		func {
			label = "func:blue:top";
			gpio = <&gpio0 9 GPIO_ACTIVE_LOW>;
		};

		power {
			label = "power:blue:bottom";
			gpio = <&gpio0 14 GPIO_ACTIVE_LOW>;
			default-state = "on";
		};
	};

	regulators {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <0>;
		pinctrl-0 = <&pmx_sata0_power &pmx_sata1_power &pmx_usb_power>;
		pinctrl-names = "default";

		sata0_power: regulator at 0 {
			compatible = "regulator-fixed";
			reg = <0>;
			regulator-name = "SATA0 Power";
			regulator-min-microvolt = <5000000>;
			regulator-max-microvolt = <5000000>;
			enable-active-high;
			regulator-always-on;
			regulator-boot-on;
			gpio = <&gpio0 1 GPIO_ACTIVE_HIGH>;
		};

		sata1_power: regulator at 1 {
			compatible = "regulator-fixed";
			reg = <1>;
			regulator-name = "SATA1 Power";
			regulator-min-microvolt = <5000000>;
			regulator-max-microvolt = <5000000>;
			enable-active-high;
			regulator-always-on;
			regulator-boot-on;
			gpio = <&gpio0 19 GPIO_ACTIVE_HIGH>;
		};

		usb_power: regulator at 2 {
			compatible = "regulator-fixed";
			reg = <2>;
			regulator-name = "USB Power";
			regulator-min-microvolt = <5000000>;
			regulator-max-microvolt = <5000000>;
			enable-active-high;
			regulator-always-on;
			regulator-boot-on;
			gpio = <&gpio0 16 GPIO_ACTIVE_HIGH>;
		};
	};
};

&devbus_bootcs {
	status = "okay";

	devbus,keep-config;

	flash at 0 {
		compatible = "cfi-flash";
		reg = <0 0x40000>;
		bank-width = <1>;
                #address-cells = <1>;
		#size-cells = <1>;

		partition at 0 {
			label = "Full256Kb";
			reg = <0 0x40000>;
			read-only;
		};
	};
};

&mdio {
	status = "okay";

	ethphy: ethernet-phy {
		reg = <8>;
	};
};

&ehci0 {
	status = "okay";
};

&eth {
	status = "okay";

	ethernet-port at 0 {
		phy-handle = <&ethphy>;
	};
};

&i2c {
	status = "okay";
	clock-frequency = <100000>;
	#address-cells = <1>;

	rtc at 32 {
		compatible = "ricoh,rs5c372a";
		reg = <0x32>;
	};
};

&pinctrl {
	pmx_buttons: pmx-buttons {
		marvell,pins = "mpp15", "mpp17", "mpp18";
		marvell,function = "gpio";
	};

	pmx_leds: pmx-leds {
		marvell,pins = "mpp2", "mpp3", "mpp9", "mpp14";
		marvell,function = "gpio";
	};

It would be normal to have four separate entries for these leds.

Otherwise, this looks pretty good.

	   Andrew