* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
@ 2009-03-13 22:35 ` David Miller
2009-03-13 22:40 ` Meelis Roos
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-03-13 22:35 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
2009-03-13 22:35 ` David Miller
@ 2009-03-13 22:40 ` Meelis Roos
2009-03-14 14:43 ` Friedrich Oslage
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Meelis Roos @ 2009-03-13 22:40 UTC (permalink / raw)
To: sparclinux
> Can you try to bisect this down or similar? I really
OK, will do.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
2009-03-13 22:35 ` David Miller
2009-03-13 22:40 ` Meelis Roos
@ 2009-03-14 14:43 ` Friedrich Oslage
2009-03-14 21:14 ` David Miller
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Friedrich Oslage @ 2009-03-14 14:43 UTC (permalink / raw)
To: sparclinux
[-- 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,
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (2 preceding siblings ...)
2009-03-14 14:43 ` Friedrich Oslage
@ 2009-03-14 21:14 ` David Miller
2009-03-14 21:42 ` Friedrich Oslage
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-03-14 21:14 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (3 preceding siblings ...)
2009-03-14 21:14 ` David Miller
@ 2009-03-14 21:42 ` Friedrich Oslage
2009-03-15 13:23 ` Meelis Roos
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Friedrich Oslage @ 2009-03-14 21:42 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (4 preceding siblings ...)
2009-03-14 21:42 ` Friedrich Oslage
@ 2009-03-15 13:23 ` Meelis Roos
2009-03-16 3:32 ` David Miller
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Meelis Roos @ 2009-03-15 13:23 UTC (permalink / raw)
To: sparclinux
> 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)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (5 preceding siblings ...)
2009-03-15 13:23 ` Meelis Roos
@ 2009-03-16 3:32 ` David Miller
2009-04-17 11:10 ` David Miller
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-03-16 3:32 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (6 preceding siblings ...)
2009-03-16 3:32 ` David Miller
@ 2009-04-17 11:10 ` David Miller
2009-04-19 9:16 ` Meelis Roos
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-04-17 11:10 UTC (permalink / raw)
To: sparclinux
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,
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (7 preceding siblings ...)
2009-04-17 11:10 ` David Miller
@ 2009-04-19 9:16 ` Meelis Roos
2009-04-19 10:18 ` David Miller
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Meelis Roos @ 2009-04-19 9:16 UTC (permalink / raw)
To: sparclinux
> 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)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (8 preceding siblings ...)
2009-04-19 9:16 ` Meelis Roos
@ 2009-04-19 10:18 ` David Miller
2009-04-21 9:16 ` David Miller
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-04-19 10:18 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (9 preceding siblings ...)
2009-04-19 10:18 ` David Miller
@ 2009-04-21 9:16 ` David Miller
2009-04-22 9:25 ` David Miller
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-04-21 9:16 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (10 preceding siblings ...)
2009-04-21 9:16 ` David Miller
@ 2009-04-22 9:25 ` David Miller
2009-04-22 9:59 ` Meelis Roos
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-04-22 9:25 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (11 preceding siblings ...)
2009-04-22 9:25 ` David Miller
@ 2009-04-22 9:59 ` Meelis Roos
2009-04-22 10:37 ` Meelis Roos
2009-04-22 10:44 ` David Miller
14 siblings, 0 replies; 16+ messages in thread
From: Meelis Roos @ 2009-04-22 9:59 UTC (permalink / raw)
To: sparclinux
> 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)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (12 preceding siblings ...)
2009-04-22 9:59 ` Meelis Roos
@ 2009-04-22 10:37 ` Meelis Roos
2009-04-22 10:44 ` David Miller
14 siblings, 0 replies; 16+ messages in thread
From: Meelis Roos @ 2009-04-22 10:37 UTC (permalink / raw)
To: sparclinux
> 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)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Ultra1 ESP detection problem
2009-03-13 22:24 Ultra1 ESP detection problem Meelis Roos
` (13 preceding siblings ...)
2009-04-22 10:37 ` Meelis Roos
@ 2009-04-22 10:44 ` David Miller
14 siblings, 0 replies; 16+ messages in thread
From: David Miller @ 2009-04-22 10:44 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 16+ messages in thread