PowerPC: Fix find_legacy_serial_ports on OPB.

PATCH In review Valentine Barshak 4 participants 11 messages Oct 11, 2007 – Oct 12, 2007 PowerPC

Share & tools

Valentine Barshak

author

2007-10-11 15:27 UTC #0 lore raw

PATCH 1/1 PowerPC: Fix find_legacy_serial_ports on OPB.

Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.

Signed-off-by Valentine Barshak <[email protected]>

---
 arch/powerpc/kernel/legacy_serial.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

arch/powerpc/kernel/legacy_serial.c +2 -2

diff -pruN linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c linux-2.6/arch/powerpc/kernel/legacy_serial.c
@@ -340,9 +340,9 @@ void __init find_legacy_serial_ports(voi
 	}
 
 	/* First fill our array with opb bus ports */
-	for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16750")) != NULL;) {
+	for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
 		struct device_node *opb = of_get_parent(np);
-		if (opb && !strcmp(opb->type, "opb")) {
+		if (opb && of_device_is_compatible(opb, "ibm,opb")) {
 			index = add_legacy_soc_port(np, np);
 			if (index >= 0 && np == stdout)
 				legacy_serial_console = index;

Arnd Bergmann

2007-10-11 15:50 UTC #1 lore raw

Quoted 10 lines · Valentine Barshak

Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>

The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").

Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.

For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.

	Arnd <><

Josh Boyer

2007-10-11 15:56 UTC #2 lore raw

Quoted 18 lines · Arnd Bergmann

Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").

Quoted 7 lines

Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.
For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.

Wait, no. We already had this discussion months ago when David was working on the original Ebony port. It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.

Have we changed our stance on that? If not, then perhaps KGDB should be fixed to work with serial_of.

josh

Arnd Bergmann

2007-10-11 17:09 UTC #3 lore raw

Quoted 7 lines · Josh Boyer

Wait, no. =A0We already had this discussion months ago when David was working on the original Ebony port. =A0It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.
=20
Have we changed our stance on that? =A0If not, then perhaps KGDB should be fixed to work with serial_of.

I guess I'm fine with a patch that removes the OPB probing from legacy_serial, but as long as it's there it should work on all platforms.

Note that of_serial and legacy_serial are not exclusive, as of_serial will simply take over all ports that have previously been registered by the legacy code. Probing them early has the advantage that you can see many printk messages earlier when the of_serial initialization has not been called yet.

	Arnd <><

Valentine Barshak

author

2007-10-11 19:10 UTC #4 lore raw

PATCH 1/1 PowerPC: Add legacy serial support for OPB with flattened device tree.

Currently find_legacy_serial_ports() can find no serial ports on the OPB with flattened device. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1 on the UART's physical address specified in kernel config. This happens because we look for ns16750 serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550-compatible devices and use of_device_is_compatible() for opb in case device type is not specified.

Signed-off-by Valentine Barshak <[email protected]>

---
 arch/powerpc/kernel/legacy_serial.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

arch/powerpc/kernel/legacy_serial.c +3 -2

diff -pruN linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c linux-2.6/arch/powerpc/kernel/legacy_serial.c
@@ -340,9 +340,10 @@ void __init find_legacy_serial_ports(voi
 	}
 
 	/* First fill our array with opb bus ports */
-	for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16750")) != NULL;) {
+	for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
 		struct device_node *opb = of_get_parent(np);
-		if (opb && !strcmp(opb->type, "opb")) {
+		if (opb && (!strcmp(opb->type, "opb") ||
+			    of_device_is_compatible(opb, "ibm,opb"))) {
 			index = add_legacy_soc_port(np, np);
 			if (index >= 0 && np == stdout)
 				legacy_serial_console = index;

Arnd Bergmann

Acked-by on v1 1/1

2007-10-11 21:11 UTC #5 lore raw

Re: [PATCH] PowerPC: Add legacy serial support for OPB with flattened device tree.

Quoted 10 lines · Valentine Barshak

Currently find_legacy_serial_ports() can find no serial ports on the OPB with flattened device. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1 on the UART's physical address specified in kernel config. This happens because we look for ns16750 serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550-compatible devices and use of_device_is_compatible() for opb in case device type is not specified.
Signed-off-by Valentine Barshak <[email protected]>

Looks correct for QS21 now.

Acked-by Arnd Bergmann <[email protected]>

Valentine Barshak

author

2007-10-11 17:27 UTC #6 lore raw

In reply to Josh Boyer

Quoted 26 lines · Josh Boyer

Quoted 17 lines · Arnd Bergmann
Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").
Quoted 7 lines
Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.
For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.

Quoted 7 lines

Wait, no. We already had this discussion months ago when David was working on the original Ebony port. It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.
Have we changed our stance on that? If not, then perhaps KGDB should be fixed to work with serial_of.

Actually I don't see any reason not to use legacy_serial stuff for early console. We could split the kernel configured very early debug output, which uses PPC_EARLY_DEBUG_44x_PHYSLOW/PHYSHIGH (since it's really dangerous) and early console things by using legacy serial. We could use
early boot console without PPC_EARLY_DEBUG_44x.
Thanks,
Valentine.

Quoted 7 lines

josh
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Josh Boyer

2007-10-11 18:35 UTC #7 lore raw

Quoted 32 lines · Valentine Barshak

Quoted 31 lines · Josh Boyer
Quoted 17 lines · Arnd Bergmann
Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").
Quoted 7 lines
Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.
For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.
Wait, no. We already had this discussion months ago when David was working on the original Ebony port. It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.

Quoted 8 lines

Quoted 2 lines
Have we changed our stance on that? If not, then perhaps KGDB should be fixed to work with serial_of.
Actually I don't see any reason not to use legacy_serial stuff for early console. We could split the kernel configured very early debug output, which uses PPC_EARLY_DEBUG_44x_PHYSLOW/PHYSHIGH (since it's really dangerous) and early console things by using legacy serial. We could use
early boot console without PPC_EARLY_DEBUG_44x.

That was exactly my thinking when this first came up. I'd like to hear David's opinion on it.

josh

David Gibson

2007-10-12 02:36 UTC #8 lore raw

Quoted 36 lines · Josh Boyer

Quoted 35 lines · Valentine Barshak
Quoted 33 lines · Josh Boyer
Quoted 17 lines · Arnd Bergmann
Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").
Quoted 7 lines
Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.
For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.
Wait, no. We already had this discussion months ago when David was working on the original Ebony port. It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.
Have we changed our stance on that? If not, then perhaps KGDB should be fixed to work with serial_of.

Quoted 8 lines

Quoted 5 lines
Actually I don't see any reason not to use legacy_serial stuff for early console. We could split the kernel configured very early debug output, which uses PPC_EARLY_DEBUG_44x_PHYSLOW/PHYSHIGH (since it's really dangerous) and early console things by using legacy serial. We could use
early boot console without PPC_EARLY_DEBUG_44x.
That was exactly my thinking when this first came up. I'd like to hear David's opinion on it.

Yeah, I think I misinterpreted BenH way back when. This looks ok, and means serial will be initialized earlier than of_serial, which would be nice.

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Josh Boyer

2007-10-12 11:52 UTC #9 lore raw

Quoted 43 lines · David Gibson

Quoted 42 lines · Josh Boyer
Quoted 40 lines · Valentine Barshak
Quoted 26 lines · Josh Boyer
Quoted 17 lines · Arnd Bergmann
Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").
Quoted 7 lines
Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.
For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.
Quoted 7 lines
Wait, no. We already had this discussion months ago when David was working on the original Ebony port. It was declared that legacy_serial is not how serial should be done on 4xx and the serial_of driver was supposed to be used instead.
Have we changed our stance on that? If not, then perhaps KGDB should be fixed to work with serial_of.
Actually I don't see any reason not to use legacy_serial stuff for early console. We could split the kernel configured very early debug output, which uses PPC_EARLY_DEBUG_44x_PHYSLOW/PHYSHIGH (since it's really dangerous) and early console things by using legacy serial. We could use
early boot console without PPC_EARLY_DEBUG_44x.

Quoted 6 lines

Quoted 2 lines
That was exactly my thinking when this first came up. I'd like to hear David's opinion on it.
Yeah, I think I misinterpreted BenH way back when. This looks ok, and means serial will be initialized earlier than of_serial, which would be nice.

Great. It seems Paul pulled it into his tree already as well, which suits me just fine.

josh

Valentine Barshak

author

2007-10-11 18:50 UTC #10 lore raw

In reply to Arnd Bergmann

Quoted 18 lines · Arnd Bergmann

Quoted 10 lines · Valentine Barshak
Currently find_legacy_serial_ports() can find no serial ports on the OPB. Thus no legacy boot console can be initialized. Just the early udbg console works, which is initialized with udbg_init_44x_as1() on the UART's physical address specified in kernel config. This happens because we look for ns16750 and higher serial devices only and expect opb node to have a device type property. This patch makes it look for ns16550 compatible devices and use of_device_is_compatible() for opb instead of checking device type. Lack of legacy serial ports found causes problems for KGDB over serial.
Signed-off-by Valentine Barshak <[email protected]>
The patch would make sense if we were only dealing with flattened device tree systems at this point. Unfortunately, IBM is shipping hardware that encodes the serial port in exactly the way that find_legacy_serial_ports is looking for (parent->type == "opb", compatible = "ns16750" "ns16550" "ns16450" i8250").

Quoted 3 lines

Changing the search for ns16750 to ns16550 should be fine, but unnecessary because AFAIK, all OPB serial imlpementations are actually ns16750 and should have that in the device tree as well.

This is a bit odd. The docs say that uart chips on the ppc44x processors are registry-compatible to 16750, but have 16-byte FIFO's. This is OK for legacy serial stuff (since it really needs the chip to be 16550-compatible), but the 8250 driver expects 64-byte FIFO size for 16750. I guess that's why 44x uart dts entries don't have 16750 compatible property.

Quoted 6 lines

For the device type of the bus, please check for both compatible and type, so that it still works on machines that are missing the compatible property.
	Arnd <><