ARM: ixp4xx regression (bisected) since v3.5-rc1

ARM: ixp4xx regression (bisected) since v3.5-rc1

[Brad Parker]

I am using an ADI Pronghorn Metro board and noticed an issue with any
kernel >= 3.5-rc1 where the board would not boot (or at least no
console messages appear over the serial port), just giving
"Uncompressing Linux... done, booting the kernel." and stopping there.

I ran a git bisect between v3.4 and v3.5 and narrowed the problem down
to this commit:

---
c23bfc3835173f5229b2503e3b616001a28affad is the first bad commit
commit c23bfc3835173f5229b2503e3b616001a28affad
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Mar 10 12:49:16 2012 +0000

    ARM: PCI: provide a default bus scan implementation
---

I then reversed this commit on 3.7.9 and the board booted
successfully. I'm not sure if this affects other boards of the same
arch or not, I only have access to a Pronghorn which also requires a
patch for the board files as they are not part of mainline.

Re: ARM: ixp4xx regression (bisected) since v3.5-rc1

[Russell King - ARM Linux]

On Sat, Feb 23, 2013 at 01:30:57AM -0500, Brad Parker wrote:
> I then reversed this commit on 3.7.9 and the board booted
> successfully. I'm not sure if this affects other boards of the same
> arch or not, I only have access to a Pronghorn which also requires a
> patch for the board files as they are not part of mainline.

So it's an externally maintained board which breaks because of changes
made in mainline?  Likely, it's not been updated for the mainline changes
correctly.  *Sigh* unmerged external platform support sucks.

What the commit you refer to above does is change the core code to do
this:

+                       if (hw->scan)
+                               sys->bus = hw->scan(nr, sys);
+                       else
+                               sys->bus = pci_scan_root_bus(NULL, sys->busnr,
+                                               hw->ops, sys, &sys->resources);

then changes each of the IXP4xx board files:

+       .ops            = &ixp4xx_ops,
-       .scan           = ixp4xx_scan_bus,

and removes this:

-struct pci_bus * __devinit ixp4xx_scan_bus(int nr, struct pci_sys_data *sys)
-{
-       return pci_scan_root_bus(NULL, sys->busnr, &ixp4xx_ops, sys,
-                                &sys->resources);
-}

What you will notice is that when .scan = NULL, and .ops = &ixp4xx_ops,
the code is exactly identical.

So, I doubt this is a regression with the mainline kernel, but is brought
about by the non-visibility of your platforms code to mainline... I think
your platform code needs updating appropriately.

Re: ARM: ixp4xx regression (bisected) since v3.5-rc1

[Brad Parker]

On Sat, Feb 23, 2013 at 4:49 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Feb 23, 2013 at 01:30:57AM -0500, Brad Parker wrote:
>> I then reversed this commit on 3.7.9 and the board booted
>> successfully. I'm not sure if this affects other boards of the same
>> arch or not, I only have access to a Pronghorn which also requires a
>> patch for the board files as they are not part of mainline.
>
> So it's an externally maintained board which breaks because of changes
> made in mainline?  Likely, it's not been updated for the mainline changes
> correctly.  *Sigh* unmerged external platform support sucks.
>
> What the commit you refer to above does is change the core code to do
> this:
>
> +                       if (hw->scan)
> +                               sys->bus = hw->scan(nr, sys);
> +                       else
> +                               sys->bus = pci_scan_root_bus(NULL, sys->busnr,
> +                                               hw->ops, sys, &sys->resources);
>
> then changes each of the IXP4xx board files:
>
> +       .ops            = &ixp4xx_ops,
> -       .scan           = ixp4xx_scan_bus,
>
> and removes this:
>
> -struct pci_bus * __devinit ixp4xx_scan_bus(int nr, struct pci_sys_data *sys)
> -{
> -       return pci_scan_root_bus(NULL, sys->busnr, &ixp4xx_ops, sys,
> -                                &sys->resources);
> -}
>
> What you will notice is that when .scan = NULL, and .ops = &ixp4xx_ops,
> the code is exactly identical.
>
> So, I doubt this is a regression with the mainline kernel, but is brought
> about by the non-visibility of your platforms code to mainline... I think
> your platform code needs updating appropriately.

You're right. I just forgot to add .ops, now it works without
reverting your commit. I think the patch could be merged in if someone
were willing to clean it up, I just don't really have the time. ADI
originally wrote the patch themselves for 2.6.26 and they claim that
it was included in 2.6.27 upstream, if that's true I assume it has
been removed at some point in the past. OpenWRT also maintains a
similar patch to get the board running on 3.3. I think the only thing
necessary to get it to 3.7/3.8 is remove .swizzle/.scan and add .ops.