Ultra1 ESP detection problem

Ultra1 ESP detection problem

[Meelis Roos]

This is an Ultra 1 SBus (non-enterprise), having onboard SCSI, sbus card 
with esp scsi and hme (FASHME) and a qlogic pti sbus card with scsi. 
Boot disk is attached to onboard scsi. 2.6.26 and earlier kernels detect 
all the scsi buses fine, 2.6.27 and 2.6.28 not yet tested, 2.6.29-rc8 
fails to detect the onboard scsi (esp: probe of f0062a74 failed with 
error -12).

Where to look next? Test 2.6.28? Instrument esp probing?

2.6.29-rc8:

[   60.565134] esp: probe of f0062a74 failed with error -12
[   60.628587] esp: esp0, regs[1ff08810000:1ff08800000] irq[14]
[   60.695018] esp: esp0 is a FASHME, 40 MHz (ccf=0), SCSI ID 7
[   63.763523] scsi1 : esp
[   67.307906] Driver 'sd' needs updating - please use bus_type methods

2.6.26-1-sparc64 debian kernel:

[   86.124210] SCSI subsystem initialized
[   86.320457] esp: esp0, regs[1ffe8800000:1ffe8400000] irq[10]
[   86.509902] esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
[   89.702355] scsi0 : esp
[   89.816311] esp: esp1, regs[1ff08810000:1ff08800000] irq[14]
[   90.004080] esp: esp1 is a FASHME, 40 MHz (ccf=0), SCSI ID 7
[   90.193412] scsi 0:0:0:0: Direct-Access     MAXTOR   ATLAS10K4_36SCA  DFV0 PQ: 0 ANSI: 3
[   90.507337]  target0:0:0: Beginning Domain Validation
[   90.683775]  target0:0:0: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
[   90.895837]  target0:0:0: Domain Validation skipping write tests
[   91.091994]  target0:0:0: Ending Domain Validation
[   92.435361] scsi 0:0:6:0: CD-ROM            TOSHIBA  XM-5401TASUN4XCD 2565 PQ: 0 ANSI: 2
[   92.749263]  target0:0:6: Beginning Domain Validation
[   92.937355]  target0:0:6: FAST-5 SCSI 4.2 MB/s ST (236 ns, offset 15)
[   93.151292]  target0:0:6: Domain Validation skipping write tests
[   93.347395]  target0:0:6: Ending Domain Validation
[   93.515353] scsi1 : esp
[   94.968095] Driver 'sd' needs updating - please use bus_type methods
[   95.244694] Driver 'sr' needs updating - please use bus_type methods
[   95.460045] sd 0:0:0:0: [sda] 71833096 512-byte hardware sectors (36779 MB)
[   95.698148] sd 0:0:0:0: [sda] Write Protect is off
[   95.865057] sd 0:0:0:0: [sda] Mode Sense: ed 00 10 08
[   95.876992] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[   96.220106] sd 0:0:0:0: [sda] 71833096 512-byte hardware sectors (36779 MB)
[   96.452241] sd 0:0:0:0: [sda] Write Protect is off
[   96.619231] sd 0:0:0:0: [sda] Mode Sense: ed 00 10 08
[   96.631215] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[   96.957698]  sda: sda1 sda2 sda3 sda4
[   97.209625] sd 0:0:0:0: [sda] Attached SCSI disk
[   97.399887] sr0: scsi-1 drive
[   97.523007] Uniform CD-ROM driver Revision: 3.20
[   97.687590] sr 0:0:6:0: Attached scsi CD-ROM sr0
[   97.741514] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   97.921258] sr 0:0:6:0: Attached scsi generic sg1 type 5

prtconf -pv under 2.6.26-1-sparc64:

System Configuration:  Sun Microsystems  sun4u
Memory size: 832 Megabytes
System Peripherals (PROM Nodes):

Node 0xf0029970
    .node:  f0029970
    energystar-v2:  
    idprom:  01800800.20886d6a.00000000.886d6aa9.00000000.00000000.10000000.00000000
    reset-reason: 'S-POR'
    breakpoint-trap:  0000007f
    #size-cells:  00000002
    model: 'SUNW,501-2836'
    name: 'SUNW,Ultra-1'
    clock-frequency:  0442ddd7
    banner-name: 'Sun Ultra 1 SBus (UltraSPARC 143MHz)'
    device_type: 'upa'

    Node 0xf002cbb4
        .node:  f002cbb4
        name: 'packages'

        Node 0xf0033d38
            .node:  f0033d38
            iso6429-1983-colors:  
            name: 'terminal-emulator'

        Node 0xf0036a74
            .node:  f0036a74
            disk-write-fix:  
            name: 'deblocker'

        Node 0xf0037150
            .node:  f0037150
            name: 'obp-tftp'

        Node 0xf0041f10
            .node:  f0041f10
            name: 'disk-label'

        Node 0xf005fc58
            .node:  f005fc58
            name: 'sun-keyboard'

    Node 0xf002cc24
        .node:  f002cc24
        stdout:  fffe6040
        stdin:  fffe6228
        mmu:  fffe8438
        memory:  fffe8638
        bootargs:  00
        bootpath: '/sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a'
        stdout-#lines:  ffffffff
        name: 'chosen'

    Node 0xf002cc90
        .node:  f002cc90
        version: 'OBP 3.35.0 2004/04/19 12:15'
        model: 'SUNW,3.35'
        decode-complete:  
        aligned-allocator:  
        relative-addressing:  
        name: 'openprom'

        Node 0xf002cd20
            .node:  f002cd20
            name: 'client-services'

    Node 0xf002cdc8
        .node:  f002cdc8
        tpe-link-test?: 'true'
        scsi-initiator-id: '7'
        keyboard-click?: 'false'
        keymap:  
        sbus-probe-list: '012'
        ttyb-rts-dtr-off: 'false'
        ttyb-ignore-cd: 'true'
        ttya-rts-dtr-off: 'false'
        ttya-ignore-cd: 'true'
        ttyb-mode: '9600,8,n,1,-'
        ttya-mode: '9600,8,n,1,-'
        mfg-mode: 'off'
        diag-level: 'max'
        #power-cycles: '1185'
        system-board-serial#: '5013051005142'
        system-board-date: '33a6c68b'
        fcode-debug?: 'false'
        output-device: 'ttya'
        input-device: 'ttya'
        load-base: '16384'
        boot-command: 'boot'
        auto-boot?: 'true'
        watchdog-reboot?: 'true'
        diag-file:  
        diag-device: 'net'
        boot-file:  
        boot-device: 'disk net'
        local-mac-address?: 'false'
        ansi-terminal?: 'true'
        screen-#columns: '80'
        screen-#rows: '34'
        silent-mode?: 'false'
        use-nvramrc?: 'false'
        nvramrc:  
        security-mode: 'none'
        security-password:  
        security-#badlogins: '0'
        oem-logo:  
        oem-logo?: 'false'
        oem-banner:  
        oem-banner?: 'false'
        hardware-revision:  
        last-hardware-update:  
        diag-switch?: 'false'
        name: 'options'

    Node 0xf002ce38
        .node:  f002ce38
        net-aui: '/sbus/ledma@e,8400010:aui/le@e,8c00000'
        net-tpe: '/sbus/ledma@e,8400010:tpe/le@e,8c00000'
        net: '/sbus/ledma@e,8400010/le@e,8c00000'
        disk: '/sbus/espdma@e,8400000/esp@e,8800000/sd@0,0'
        cdrom: '/sbus/espdma@e,8400000/esp@e,8800000/sd@6,0:f'
        tape: '/sbus/espdma@e,8400000/esp@e,8800000/st@4,0'
        tape1: '/sbus/espdma@e,8400000/esp@e,8800000/st@5,0'
        tape0: '/sbus/espdma@e,8400000/esp@e,8800000/st@4,0'
        disk6: '/sbus/espdma@e,8400000/esp@e,8800000/sd@6,0'
        disk5: '/sbus/espdma@e,8400000/esp@e,8800000/sd@5,0'
        disk4: '/sbus/espdma@e,8400000/esp@e,8800000/sd@4,0'
        disk3: '/sbus/espdma@e,8400000/esp@e,8800000/sd@3,0'
        disk2: '/sbus/espdma@e,8400000/esp@e,8800000/sd@2,0'
        disk1: '/sbus/espdma@e,8400000/esp@e,8800000/sd@1,0'
        disk0: '/sbus/espdma@e,8400000/esp@e,8800000/sd@0,0'
        scsi: '/sbus/espdma@e,8400000/esp@e,8800000'
        floppy: '/sbus/SUNW,fdtwo'
        ttyb: '/sbus/zs@f,1100000:b'
        ttya: '/sbus/zs@f,1100000:a'
        keyboard!: '/sbus/zs@f,1000000:forcemode'
        keyboard: '/sbus/zs@f,1000000'
        name: 'aliases'

    Node 0xf004cadc
        .node:  f004cadc
        reg:  00000000.00000000.00000000.10000000.00000000.10000000.00000000.10000000.00000000.20000000.00000000.10000000.00000000.30000000.00000000.04000000
        available:  00000000.33f3c000.00000000.00014000.00000000.33f00000.00000000.00036000.00000000.00000000.00000000.33efe000
        name: 'memory'

    Node 0xf004d0bc
        .node:  f004d0bc
        translations:  00000000.fffe0000.00000000.00010000.80000000.33f700b6.00000000.fffd8000.00000000.00008000.80000000.33f600b6.00000000.fffcc000.00000000.00008000.800001fe.0000008e.00000000.fffc8000.00000000.00004000.80000000.33f5c0b6.00000000.fffc6000.00000000.00002000.800001fe.0000208e.00000000.fffc4000.00000000.00002000.800001fe.0000208e.00000000.fffc2000.00000000.00002000.800001fe.0000208e.00000000.fffc0000.00000000.00002000.800001ff.f120008e.00000000.fffbe000.00000000.00002000.800001ff.f120008e.00000000.fffbc000.00000000.00002000.800001ff.f130008e.00000000.fffba000.00000000.00002000.800001ff.f190008e.00000000.fffb8000.00000000.00002000.800001ff.f100008e.00000000.fffb6000.00000000.00002000.80000000.33efe0b6.00000000.fffb4000.00000000.00002000.80000000.33f580b6.00000000.fffb2000.00000000.00002000.800001ff.f140008e.00000000.fffb0000.00000000.00002000.800001ff.f110008e.00000000.fffa0000.00000000.00002000.80000000.33f560b6.00000000.f0080000.00000000.00002000.80000000.33f5
 40b6.00000000.f0000000.00000000.00080000.80000000.33f800b6.00000000.40000000.00000000.00800000.80000000.00400036.00000000.00002000.00000000.009fe000.80000000.00002036
        existing:  00000000.00000000.00000800.00000000.fffff800.00000000.00000800.00000000
        available:  fffff800.00000000.000007fc.00000000.00000001.00000000.000007ff.00000000.00000000.ffff0000.00000000.0000e000.00000000.00000000.00000000.f0000000.00000000.fffa2000.00000000.0000e000.00000000.fff00000.00000000.000a0000.00000000.f0800000.00000000.0e800000
        page-size:  00002000
        name: 'virtual-memory'

    Node 0xf00595dc
        .node:  f00595dc
        address:  fffc7c00.fffc5860.fffc3060
        interrupts:  000007f0.000007f1
        reg:  000001fe.00003c00.00000000.00000020.000001fe.00003860.00000000.00000010.000001fe.00003060.00000000.00000010
        name: 'counter-timer'

    Node 0xf0059940
        .node:  f0059940
        scsi-initiator-id:  00000007
        version#:  00000001
        implementation#:  00000000
        address:  fffcc000
        interrupts:  000007f4.000007f5.000007f6.000007e5.000007ea.000007f7
        ranges:  00000000.00000000.000001ff.00000000.10000000.00000001.00000000.000001ff.10000000.10000000.00000002.00000000.000001ff.20000000.10000000.00000003.00000000.000001ff.30000000.10000000.0000000d.00000000.000001ff.d0000000.10000000.0000000e.00000000.000001ff.e0000000.10000000.0000000f.00000000.000001ff.f0000000.10000000
        reg:  000001fe.00000000.00000000.00008000
        slot-address-bits:  0000001c
        up-burst-sizes:  0078007f
        burst-sizes:  00f8007f
        device_type: 'sbus'
        name: 'sbus'
        model: 'SUNW,sysio'
        thermal-interrupt:  
        bus-parity-generated:  
        upa-portid:  0000001f
        clock-frequency:  017d7840

        Node 0xf0059e44
            .node:  f0059e44
            internal-loopback:  
            dma-model: 'apcdma'
            interrupts:  00000024
            reg:  0000000d.0c000000.00000200
            name: 'SUNW,CS4231'

        Node 0xf0059f50
            .node:  f0059f50
            address:  fffba000
            reg:  0000000f.01900000.00000001
            name: 'auxio'

        Node 0xf0059fe0
            .node:  f0059fe0
            version:  4f425020.332e3335.2e302032.3030342f.30342f31.39203132.3a313500.504f5354.20332e31.302e3620.31393936.2f31302f.31382031.303a3139.00
            model: 'SUNW,525-1410'
            reg:  0000000f.00000000.00080000.0000000f.01380000.00080000
            name: 'flashprom'

        Node 0xf005a0a8
            .node:  f005a0a8
            status: 'disabled'
            device_type: 'block'
            interrupts:  00000029
            reg:  0000000f.01400000.00000008
            name: 'SUNW,fdtwo'

        Node 0xf005a1dc
            .node:  f005a1dc
            address:  fffbe000
            reg:  0000000f.01200000.00002000
            model: 'mk48t59'
            name: 'eeprom'

        Node 0xf005a290
            .node:  f005a290
            port-b-ignore-cd:  
            port-a-ignore-cd:  
            reg:  0000000f.01100000.00000004
            interrupts:  00000028
            device_type: 'serial'
            name: 'zs'

        Node 0xf005b730
            .node:  f005b730
            reg:  0000000f.01000000.00000004
            interrupts:  00000028
            port-b-ignore-cd:  
            port-a-ignore-cd:  
            keyboard:  
            device_type: 'serial'
            name: 'zs'

        Node 0xf005d18c
            .node:  f005d18c
            address:  fffbc000
            model: 'SUNW,sc-up'
            reg:  0000000f.01300000.00000008
            name: 'sc'

        Node 0xf005d240
            .node:  f005d240
            freq-syn: 'MC12429'
            reg:  0000000f.01304000.00000003
            name: 'SUNW,pll'

        Node 0xf0062784
            .node:  f0062784
            reg:  0000000e.08400000.00000010
            name: 'espdma'

            Node 0xf0062a74
                .node:  f0062a74
                device_type: 'scsi'
                clock-frequency:  02625a00
                interrupts:  00000020
                reg:  0000000e.08800000.00000040
                name: 'esp'

                Node 0xf0065348
                    .node:  f0065348
                    device_type: 'block'
                    name: 'sd'

                Node 0xf0065e54
                    .node:  f0065e54
                    device_type: 'byte'
                    name: 'st'

        Node 0xf0066ae4
            .node:  f0066ae4
            burst-sizes:  0000003f
            reg:  0000000e.08400010.00000020
            name: 'ledma'

            Node 0xf006707c
                .node:  f006707c
                device_type: 'network'
                busmaster-regval:  00000007
                interrupts:  00000021
                reg:  0000000e.08c00000.00000004
                name: 'le'

        Node 0xf0069908
            .node:  f0069908
            reg:  0000000e.0c800000.0000001c
            interrupts:  00000022
            name: 'SUNW,bpp'

        Node 0xf006be34
            .node:  f006be34
            hm-rev:  00000022
            model: 'SUNW,501-2739'
            device_type: 'network'
            intr:  00000004.00000000
            interrupts:  00000004
            address-bits:  00000030
            max-frame-size:  00004000
            reg:  00000000.08c00000.00000108.00000000.08c02000.00002000.00000000.08c04000.00002000.00000000.08c06000.00002000.00000000.08c07000.00000020
            name: 'SUNW,hme'

        Node 0xf00735ac
            .node:  f00735ac
            hm-rev:  00000022
            device_type: 'scsi'
            clock-frequency:  02625a00
            intr:  00000003.00000000
            interrupts:  00000003
            reg:  00000000.08800000.00000010.00000000.08810000.00000040
            name: 'SUNW,fas'

            Node 0xf007831c
                .node:  f007831c
                device_type: 'block'
                name: 'sd'

            Node 0xf0078bd8
                .node:  f0078bd8
                device_type: 'byte'
                name: 'st'

        Node 0xf00798c4
            .node:  f00798c4
            scsi-initiator-id:  00000007
            isp-fcode: '1.21 95/05/18'
            device_type: 'scsi'
            intr:  00000003.00000000
            interrupts:  00000003
            wide:  00
            clock-frequency:  02625a00
            reg:  00000001.00010000.00000450
            64-bit-clean:  00
            model: 'QLGC,ISP1000'
            name: 'QLGC,isp'

            Node 0xf007f130
                .node:  f007f130
                device_type: 'block'
                name: 'sd'

            Node 0xf007f944
                .node:  f007f944
                device_type: 'byte'
                name: 'st'

    Node 0xf006b9d0
        .node:  f006b9d0
        manufacturer#:  00000017
        implementation#:  00000010
        mask#:  00000040
        sparc-version:  00000009
        ecache-associativity:  00000001
        ecache-line-size:  00000040
        ecache-size:  00080000
        #dtlb-entries:  00000040
        dcache-associativity:  00000001
        dcache-line-size:  00000020
        dcache-size:  00004000
        #itlb-entries:  00000040
        icache-associativity:  00000002
        icache-line-size:  00000020
        icache-size:  00004000
        upa-portid:  00000000
        clock-frequency:  0885bbae
        reg:  000001c0.00000000.00000000.00000008
        device_type: 'cpu'
        name: 'SUNW,UltraSPARC'



-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Sat, 14 Mar 2009 00:24:31 +0200 (EET)

> This is an Ultra 1 SBus (non-enterprise), having onboard SCSI, sbus card 
> with esp scsi and hme (FASHME) and a qlogic pti sbus card with scsi. 
> Boot disk is attached to onboard scsi. 2.6.26 and earlier kernels detect 
> all the scsi buses fine, 2.6.27 and 2.6.28 not yet tested, 2.6.29-rc8 
> fails to detect the onboard scsi (esp: probe of f0062a74 failed with 
> error -12).

	host = scsi_host_alloc(tpnt, sizeof(struct esp));

	err = -ENOMEM;
	if (!host)
		goto fail;

This is what's failing since -12 is -ENOMEM.

Can you try to bisect this down or similar?  I really
can guarentee you that I have to delete this report since
I'm so backlogged I won't get to it for a very long time.

Thanks.

Re: Ultra1 ESP detection problem

[Meelis Roos]

> Can you try to bisect this down or similar?  I really

OK, will do.

-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[Friedrich Oslage]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Meelis Roos schrieb:
> [   60.565134] esp: probe of f0062a74 failed with error -12

I can reproduce this on my Ultra 2. I didn't notice it until now because
the boot disk is attached to an hme esp(which still works).

In esp_sbus_map_regs the of_ioremap call failes because res->start is 0
for non hme cards.

Basicly your tree looks like this:

SUNW,Ultra-1
  sbus
    SUNW,fas
    espdma
      esp

Of_bus_sbus_match works for "SUNW,fas" but not for "esp" because it only
checks the direct parent and not the parent's parent for name == "sbus".

This makes the kernel use of_bus_default_count_cells to calculate the
resources for "esp" instead of of_bus_sbus_count_cells.
And since of_bus_default_count_cells doesn't work for sbus systems the
resources of "esp" aren't detected.

I attached a patch, let me know if it works for you.

Cheers,
Friedrich

[-- Attachment #2: of_bus_sbus_match.patch --]
[-- Type: text/x-patch, Size: 2281 bytes --]

sparc: of_bus_sbus_match must also check the parent's parents.

To determine wheter the bus is sbus not only the direct parent but all the
parents of the parent must be checked, too.

In a tree like this

SUNW,Ultra-2
  sbus
    SUNW,hme
    SUNW,fas
    dma/espdma
      esp

only checking the direct parent would make of_match_bus use
of_bus_default_count_cells for "esp", instead of the desired
of_bus_sbus_count_cells, and return an incorrect cell count. Which, in this
case, would make allocating resources for "esp" fail.

Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Friedrich Oslage <bluebird@gentoo.org>
---
 arch/sparc/kernel/of_device_32.c |   13 +++++++++++--
 arch/sparc/kernel/of_device_64.c |   13 +++++++++++--
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 0a83bd7..bee16a5 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -246,8 +246,17 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	/* return true if the direct parent or any of the parent's parents is
+	 * "sbus" or "sbi"
+	 */
+	struct device_node *dp = np;
+
+	do {
+		if (!strcmp(dp->name, "sbus") || !strcmp(dp->name, "sbi"))
+			return 1;
+	} while ((dp = dp->parent));
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index b4a12c9..7a27cfd 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -301,8 +301,17 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	/* return true if the direct parent or any of the parent's parents is
+	 * "sbus" or "sbi"
+	 */
+	struct device_node *dp = np;
+
+	do {
+		if (!strcmp(dp->name, "sbus") || !strcmp(dp->name, "sbi"))
+			return 1;
+	} while ((dp = dp->parent));
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,

Re: Ultra1 ESP detection problem

[David Miller]

From: Friedrich Oslage <bluebird@gentoo.org>
Date: Sat, 14 Mar 2009 15:43:07 +0100

> Meelis Roos schrieb:
> > [   60.565134] esp: probe of f0062a74 failed with error -12
> 
> I can reproduce this on my Ultra 2. I didn't notice it until now because
> the boot disk is attached to an hme esp(which still works).
> 
> In esp_sbus_map_regs the of_ioremap call failes because res->start is 0
> for non hme cards.
> 
> Basicly your tree looks like this:
> 
> SUNW,Ultra-1
>   sbus
>     SUNW,fas
>     espdma
>       esp
> 
> Of_bus_sbus_match works for "SUNW,fas" but not for "esp" because it only
> checks the direct parent and not the parent's parent for name = "sbus".
> 
> This makes the kernel use of_bus_default_count_cells to calculate the
> resources for "esp" instead of of_bus_sbus_count_cells.
> And since of_bus_default_count_cells doesn't work for sbus systems the
> resources of "esp" aren't detected.

Grumble, I've fixed this already.  See the patch below which has
been in the tree for a while.

We need to figure out why the logic isn't triggering properly.

commit 5280267c1dddb8d413595b87dc406624bb497946
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Sep 3 02:04:41 2008 -0700

    sparc: Fix handling of LANCE and ESP parent nodes in of_device.c
    
    The device nodes that sit above 'esp' and 'le' on SBUS lack a 'ranges'
    property, but we should pass the translation up to the parent node so
    that the SBUS level ranges get applied.
    
    Based upon a bug report from Robert Reif.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
index c590148..4ef1607 100644
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -344,6 +344,27 @@ static int __init build_one_resource(struct device_node *parent,
 	return 1;
 }
 
+static int __init use_1to1_mapping(struct device_node *pp)
+{
+	/* If we have a ranges property in the parent, use it.  */
+	if (of_find_property(pp, "ranges", NULL) != NULL)
+		return 0;
+
+	/* Some SBUS devices use intermediate nodes to express
+	 * hierarchy within the device itself.  These aren't
+	 * real bus nodes, and don't have a 'ranges' property.
+	 * But, we should still pass the translation work up
+	 * to the SBUS itself.
+	 */
+	if (!strcmp(pp->name, "dma") ||
+	    !strcmp(pp->name, "espdma") ||
+	    !strcmp(pp->name, "ledma") ||
+	    !strcmp(pp->name, "lebuffer"))
+		return 0;
+
+	return 1;
+}
+
 static int of_resource_verbose;
 
 static void __init build_device_resources(struct of_device *op,
@@ -389,10 +410,7 @@ static void __init build_device_resources(struct of_device *op,
 
 		memcpy(addr, reg, na * 4);
 
-		/* If the immediate parent has no ranges property to apply,
-		 * just use a 1<->1 mapping.
-		 */
-		if (of_find_property(pp, "ranges", NULL) = NULL) {
+		if (use_1to1_mapping(pp)) {
 			result = of_read_addr(addr, na);
 			goto build_res;
 		}
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index e427086..c15bcdf 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -438,8 +438,17 @@ static int __init use_1to1_mapping(struct device_node *pp)
 
 	/* If the parent is the dma node of an ISA bus, pass
 	 * the translation up to the root.
+	 *
+	 * Some SBUS devices use intermediate nodes to express
+	 * hierarchy within the device itself.  These aren't
+	 * real bus nodes, and don't have a 'ranges' property.
+	 * But, we should still pass the translation work up
+	 * to the SBUS itself.
 	 */
-	if (!strcmp(pp->name, "dma"))
+	if (!strcmp(pp->name, "dma") ||
+	    !strcmp(pp->name, "espdma") ||
+	    !strcmp(pp->name, "ledma") ||
+	    !strcmp(pp->name, "lebuffer"))
 		return 0;
 
 	/* Similarly for all PCI bridges, if we get this far

Re: Ultra1 ESP detection problem

[Friedrich Oslage]

David Miller schrieb:
> We need to figure out why the logic isn't triggering properly.

That's easy, because the code isn't reached :)

In build_device_resources we have

	bus->count_cells(op->node, &na, &ns);
	preg = of_get_property(op->node, bus->addr_prop_name, &num_reg);

which, for the esp, results in

	na = 2;
	ns = 2; # this should be 1 according to of_bus_sbus_count_cells
	num_reg = 12;

after doing the maths

	num_reg /= 4;
	num_reg /= na + ns;

we end up with num_reg = 0 and the for loop is skipped.

That's why I changed of_bus_sbus_match to make cell_count return 2, 1
for the esp.

Cheers,
Friedrich

Re: Ultra1 ESP detection problem

[Meelis Roos]

> I attached a patch, let me know if it works for you.

It works, thank you!

[   43.147216] esp: esp0, regs[1ffe8800000:1ffe8400000] irq[10]
[   43.213133] esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
[   46.291912] scsi0 : esp
[   46.323301] scsi 0:0:0:0: Direct-Access     MAXTOR   ATLAS10K4_36SCA  DFV0 PQ: 0 ANSI: 3
[   46.418551] scsi target0:0:0: Beginning Domain Validation
[   46.485859] scsi target0:0:0: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
[   46.568915] scsi target0:0:0: Domain Validation skipping write tests
[   46.643444] scsi target0:0:0: Ending Domain Validation
[   47.884605] scsi 0:0:6:0: CD-ROM            TOSHIBA  XM-5401TASUN4XCD 2565 PQ: 0 ANSI: 2
[   47.979808] scsi target0:0:6: Beginning Domain Validation
[   48.058500] scsi target0:0:6: FAST-5 SCSI 4.2 MB/s ST (236 ns, offset 15)
[   48.145698] scsi target0:0:6: Domain Validation skipping write tests
[   48.219925] scsi target0:0:6: Ending Domain Validation
[   48.290452] esp: esp1, regs[1ff08810000:1ff08800000] irq[14]
[   48.356317] esp: esp1 is a FASHME, 40 MHz (ccf=0), SCSI ID 7
[   51.432077] scsi1 : esp
[   54.975344] Driver 'sd' needs updating - please use bus_type methods
[   55.051093] sd 0:0:0:0: [sda] 71833096 512-byte hardware sectors: (36.7 GB/34.2 GiB)
[   55.144227] sd 0:0:0:0: [sda] Write Protect is off
[   55.199693] sd 0:0:0:0: [sda] Mode Sense: ed 00 10 08
[   55.261650] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[   55.364374] sd 0:0:0:0: [sda] 71833096 512-byte hardware sectors: (36.7 GB/34.2 GiB)
[   55.457911] sd 0:0:0:0: [sda] Write Protect is off
[   55.513420] sd 0:0:0:0: [sda] Mode Sense: ed 00 10 08
[   55.575465] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[   55.677044]  sda: sda1 sda2 sda3 sda4
[   55.725075] sd 0:0:0:0: [sda] Attached SCSI disk
[   62.519240] Driver 'sr' needs updating - please use bus_type methods
[   63.493504] sr0: scsi-1 drive
[   63.527163] Uniform CD-ROM driver Revision: 3.20
[   63.583676] sr 0:0:6:0: Attached scsi CD-ROM sr0
[   64.471604] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   64.533811] sr 0:0:6:0: Attached scsi generic sg1 type 5


-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[David Miller]

From: Friedrich Oslage <bluebird@gentoo.org>
Date: Sat, 14 Mar 2009 22:42:56 +0100

> David Miller schrieb:
> > We need to figure out why the logic isn't triggering properly.
> 
> That's easy, because the code isn't reached :)
> 
> In build_device_resources we have
> 
> 	bus->count_cells(op->node, &na, &ns);
> 	preg = of_get_property(op->node, bus->addr_prop_name, &num_reg);
> 
> which, for the esp, results in
> 
> 	na = 2;
> 	ns = 2; # this should be 1 according to of_bus_sbus_count_cells
> 	num_reg = 12;
> 
> after doing the maths
> 
> 	num_reg /= 4;
> 	num_reg /= na + ns;
> 
> we end up with num_reg = 0 and the for loop is skipped.
> 
> That's why I changed of_bus_sbus_match to make cell_count return 2, 1
> for the esp.

Ok, but your change will break cases where the parent between SBUS
and the child device really does translate things differently.

One such case is QFE.

Look at the qec-->qe hierarchy in the ss1000 entry of the prtconfs
GIT repo:

            Node 0xffd992ec
                ranges:  00000000.00000000.00000001.00030000.00004000.00000001.00000000.00000001.00034000.00004000.00000002.00000000.00000001.00038000.00004000.00000003.00000000.00000001.0003c000.00004000.00000010.00000000.00000001.00010000.00004000.00000011.00000000.00000001.00014000.00004000.00000012.00000000.00000001.00018000.00004000.00000013.00000000.00000001.0001c000.00004000
                name:  'qec'

                Node 0xffd9ac44
                    name:  'qe'

                Node 0xffd9df24
                    name:  'qe'

                Node 0xffd9e39c
                    name:  'qe'

                Node 0xffd9e814
                    name:  'qe'

Your change will make the 'qe' nodes match SBUS as a bus.  That's
wrong, and we need to use na = 2 and ns = 2 for this case.

So this doesn't work as a mechanism to bypass intermediate parent
nodes up to the SBUS.  You need to fix this while preserving the
invariants and expectations of how this translation system works.

For now, perhaps we can add those use_1to1_mapping() checks to
of_bus_sbus_match() as a quick fix that won't break other cases like
the 'qec' mentioned above.

Re: Ultra1 ESP detection problem

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Sun, 15 Mar 2009 20:32:36 -0700 (PDT)

> Your change will make the 'qe' nodes match SBUS as a bus.  That's
> wrong, and we need to use na = 2 and ns = 2 for this case.
> 
> So this doesn't work as a mechanism to bypass intermediate parent
> nodes up to the SBUS.  You need to fix this while preserving the
> invariants and expectations of how this translation system works.
> 
> For now, perhaps we can add those use_1to1_mapping() checks to
> of_bus_sbus_match() as a quick fix that won't break other cases like
> the 'qec' mentioned above.

Ok, following through on this... Here is how I would like to
fix this bug.

sparc: Fix bus type probing for ESP and LE devices.

If there is a dummy "espdma" or "ledma" parent device above ESP scsi
or LE ethernet device nodes, we have to match the bus as SBUS.

Otherwise the address and size cell counts are wrong and we don't
calculate the final physical device resource values correctly at all.

Commit 5280267c1dddb8d413595b87dc406624bb497946 ("sparc: Fix handling
of LANCE and ESP parent nodes in of_device.c") was meant to fix this
problem, but that only influences the inner loop of
build_device_resources().  We need this logic to also kick in at the
beginning of build_device_resources() as well, when we make the first
attempt to determine the device's immediate parent bus type for 'reg'
property element extraction.

Based almost entirely upon a patch by Friedrich Oslage.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 0a83bd7..a7164c5 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -246,8 +246,25 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	struct device_node *dp = np;
+
+	while (dp) {
+		if (!strcmp(np->name, "sbus") ||
+		    !strcmp(np->name, "sbi"))
+			return 1;
+
+		/* Have a look at use_1to1_mapping().  We're trying
+		 * to match SBUS if that's the top-level bus and we
+		 * don't have some intervening real bus that provides
+		 * ranges based translations.
+		 */
+		if (of_find_property(dp, "ranges", NULL) != NULL)
+			break;
+
+		dp = dp->parent;
+	}
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 27381f1..734f7ba 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -300,8 +300,25 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	struct device_node *dp = np;
+
+	while (dp) {
+		if (!strcmp(np->name, "sbus") ||
+		    !strcmp(np->name, "sbi"))
+			return 1;
+
+		/* Have a look at use_1to1_mapping().  We're trying
+		 * to match SBUS if that's the top-level bus and we
+		 * don't have some intervening real bus that provides
+		 * ranges based translations.
+		 */
+		if (of_find_property(dp, "ranges", NULL) != NULL)
+			break;
+
+		dp = dp->parent;
+	}
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,

Re: Ultra1 ESP detection problem

[Meelis Roos]

> Ok, following through on this... Here is how I would like to
> fix this bug.
> 
> sparc: Fix bus type probing for ESP and LE devices.
> 
> If there is a dummy "espdma" or "ledma" parent device above ESP scsi
> or LE ethernet device nodes, we have to match the bus as SBUS.

Unfortunately it does not work, onboard ESP is still not detected on my 
Ultra 1.

-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 19 Apr 2009 12:16:21 +0300 (EEST)

>> Ok, following through on this... Here is how I would like to
>> fix this bug.
>> 
>> sparc: Fix bus type probing for ESP and LE devices.
>> 
>> If there is a dummy "espdma" or "ledma" parent device above ESP scsi
>> or LE ethernet device nodes, we have to match the bus as SBUS.
> 
> Unfortunately it does not work, onboard ESP is still not detected on my 
> Ultra 1.

Thanks for testing.  I'll try to figure out why it doesn't work.

Re: Ultra1 ESP detection problem

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 19 Apr 2009 12:16:21 +0300 (EEST)

>> Ok, following through on this... Here is how I would like to
>> fix this bug.
>> 
>> sparc: Fix bus type probing for ESP and LE devices.
>> 
>> If there is a dummy "espdma" or "ledma" parent device above ESP scsi
>> or LE ethernet device nodes, we have to match the bus as SBUS.
> 
> Unfortunately it does not work, onboard ESP is still not detected on my 
> Ultra 1.

Silly bug in that patch, I forgot to substitude "np" with "dp" in
the name tests that got moved into the loop.

Please try this patch instead.

Thanks!

sparc: Fix bus type probing for ESP and LE devices.

If there is a dummy "espdma" or "ledma" parent device above ESP scsi
or LE ethernet device nodes, we have to match the bus as SBUS.

Otherwise the address and size cell counts are wrong and we don't
calculate the final physical device resource values correctly at all.

Commit 5280267c1dddb8d413595b87dc406624bb497946 ("sparc: Fix handling
of LANCE and ESP parent nodes in of_device.c") was meant to fix this
problem, but that only influences the inner loop of
build_device_resources().  We need this logic to also kick in at the
beginning of build_device_resources() as well, when we make the first
attempt to determine the device's immediate parent bus type for 'reg'
property element extraction.

Based almost entirely upon a patch by Friedrich Oslage.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 arch/sparc/kernel/of_device_32.c |   21 +++++++++++++++++++--
 arch/sparc/kernel/of_device_64.c |   21 +++++++++++++++++++--
 2 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 0a83bd7..c8f14c1 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -246,8 +246,25 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	struct device_node *dp = np;
+
+	while (dp) {
+		if (!strcmp(dp->name, "sbus") ||
+		    !strcmp(dp->name, "sbi"))
+			return 1;
+
+		/* Have a look at use_1to1_mapping().  We're trying
+		 * to match SBUS if that's the top-level bus and we
+		 * don't have some intervening real bus that provides
+		 * ranges based translations.
+		 */
+		if (of_find_property(dp, "ranges", NULL) != NULL)
+			break;
+
+		dp = dp->parent;
+	}
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 27381f1..5ac287a 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -300,8 +300,25 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags)
 
 static int of_bus_sbus_match(struct device_node *np)
 {
-	return !strcmp(np->name, "sbus") ||
-		!strcmp(np->name, "sbi");
+	struct device_node *dp = np;
+
+	while (dp) {
+		if (!strcmp(dp->name, "sbus") ||
+		    !strcmp(dp->name, "sbi"))
+			return 1;
+
+		/* Have a look at use_1to1_mapping().  We're trying
+		 * to match SBUS if that's the top-level bus and we
+		 * don't have some intervening real bus that provides
+		 * ranges based translations.
+		 */
+		if (of_find_property(dp, "ranges", NULL) != NULL)
+			break;
+
+		dp = dp->parent;
+	}
+
+	return 0;
 }
 
 static void of_bus_sbus_count_cells(struct device_node *child,
-- 
1.6.2.4

Re: Ultra1 ESP detection problem

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 21 Apr 2009 02:16:31 -0700 (PDT)

> From: Meelis Roos <mroos@linux.ee>
> Date: Sun, 19 Apr 2009 12:16:21 +0300 (EEST)
> 
>>> Ok, following through on this... Here is how I would like to
>>> fix this bug.
>>> 
>>> sparc: Fix bus type probing for ESP and LE devices.
>>> 
>>> If there is a dummy "espdma" or "ledma" parent device above ESP scsi
>>> or LE ethernet device nodes, we have to match the bus as SBUS.
>> 
>> Unfortunately it does not work, onboard ESP is still not detected on my 
>> Ultra 1.
> 
> Silly bug in that patch, I forgot to substitude "np" with "dp" in
> the name tests that got moved into the loop.
> 
> Please try this patch instead.
> 
> Thanks!

Meelis, have you have an opportunity to test this updated
version of the fix yet?

Thanks.

Re: Ultra1 ESP detection problem

[Meelis Roos]

> Meelis, have you have an opportunity to test this updated
> version of the fix yet?

It was still compiling 2 hour ago, will see in an hour or two.

-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[Meelis Roos]

> Meelis, have you have an opportunity to test this updated
> version of the fix yet?

The compile had finished, I installed and testbooted it. It works, thank 
you! Tested against yesterdays git.

-- 
Meelis Roos (mroos@linux.ee)

Re: Ultra1 ESP detection problem

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 22 Apr 2009 13:37:11 +0300 (EEST)

>> Meelis, have you have an opportunity to test this updated
>> version of the fix yet?
> 
> The compile had finished, I installed and testbooted it. It works, thank 
> you! Tested against yesterdays git.

Thanks a lot for all of your help.

I'll push this fix to Linus and -stable.