[RFC 0/5] of: Automatic console registration cleanups

[RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

Hi all,

This is a series that I've been playing with over the last few days to
clean up the selection of default console devices when using the device
tree. The device tree defines a way of specifying the console by using a
"stdout-path" property in the /chosen node, but very few drivers
actually attempt to use that data, and so for most platforms there needs
to be a "console=" line in the command line if a serial port is intended
to be used as the console.

With this series, if there is a /chosen/stdout-path property, and if
that property points to a serial port node, then when the serial driver
registers the port, the core uart_add_one_port() function will notice
and if no console= argument was provided then add it as a preferred
console.

I've not tested this very extensively yet, but I want to get some
feedback before I go further.

The one downside with this approach is that it doesn't do anything for
early console setup. That still needs to be added on a per-driver basis,
but at least it shouldn't conflict with this approach.

[RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Grant Likely]

ePAPR 1.1 defines the "stdout-path" property for specifying the console
device, but Linux currently only handles the older "linux,stdout-path"
property. This patch adds parsing for the new property name.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
---
 drivers/of/base.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 418a4ff9d97c..be2861d69b02 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1955,9 +1955,9 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
 		of_chosen = of_find_node_by_path("/chosen@0");
 
 	if (of_chosen) {
-		const char *name;
-
-		name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+		const char *name = of_get_property(of_chosen, "stdout-path", NULL);
+		if (!name)
+			name = of_get_property(of_chosen, "linux,stdout-path", NULL);
 		if (name)
 			of_stdout = of_find_node_by_path(name);
 	}
-- 
1.8.3.2

[RFC 2/5] of: Create of_console_check() for selecting a console specified in /chosen

[Grant Likely]

The devicetree has a binding for specifying the console device in the
/chosen node, but the kernel doesn't use it consistently. This change
adds an API for testing if a device node is a console, and adds a
preferred console entry if it is.

At the same time this patch removes the of_device_is_stdout_path() API
since it is unused.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
---
 drivers/of/base.c  | 23 +++++++++++++----------
 include/linux/of.h |  6 +++---
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index be2861d69b02..a5643badeb1d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -17,6 +17,7 @@
  *      as published by the Free Software Foundation; either version
  *      2 of the License, or (at your option) any later version.
  */
+#include <linux/console.h>
 #include <linux/ctype.h>
 #include <linux/cpu.h>
 #include <linux/module.h>
@@ -2073,20 +2074,22 @@ const char *of_prop_next_string(struct property *prop, const char *cur)
 EXPORT_SYMBOL_GPL(of_prop_next_string);
 
 /**
- * of_device_is_stdout_path - check if a device node matches the
- *                            linux,stdout-path property
- *
- * Check if this device node matches the linux,stdout-path property
- * in the chosen node. return true if yes, false otherwise.
+ * of_console_check() - Test and setup console for DT setup
+ * @dn - Pointer to device node
+ * @name - Name to use for preferred console without index. ex. "ttyS"
+ * @index - Index to use for preferred console.
+ *
+ * Check if the given device node matches the stdout-path property in the
+ * /chosen node. If it does then register it as the preferred console and return
+ * TRUE. Otherwise return FALSE.
  */
-int of_device_is_stdout_path(struct device_node *dn)
+bool of_console_check(struct device_node *dn, char *name, int index)
 {
-	if (!of_stdout)
+	if (!dn || dn != of_stdout || console_set_on_cmdline)
 		return false;
-
-	return of_stdout == dn;
+	return add_preferred_console(name, index, NULL);
 }
-EXPORT_SYMBOL_GPL(of_device_is_stdout_path);
+EXPORT_SYMBOL_GPL(of_console_check);
 
 /**
  *	of_find_next_cache_node - Find a node's subsidiary cache
diff --git a/include/linux/of.h b/include/linux/of.h
index a8b9dad90c64..417945ebd8e1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -343,7 +343,7 @@ const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
  */
 const char *of_prop_next_string(struct property *prop, const char *cur);
 
-int of_device_is_stdout_path(struct device_node *dn);
+bool of_console_check(struct device_node *dn, char *name, int index);
 
 #else /* CONFIG_OF */
 
@@ -544,9 +544,9 @@ static inline int of_machine_is_compatible(const char *compat)
 	return 0;
 }
 
-static inline int of_device_is_stdout_path(struct device_node *dn)
+static bool of_console_check(const struct device_node *dn, const char *name, int index)
 {
-	return 0;
+	return false;
 }
 
 static inline const __be32 *of_prop_next_u32(struct property *prop,
-- 
1.8.3.2

[RFC 3/5] of: Enable console on serial ports specified by /chosen/stdout-path

[Grant Likely]

If the devicetree specifies a serial port as a stdout device, then the
kernel can use it as the default console if nothing else was selected on
the command line. For any serial port that uses the uart_add_one_port()
feature, the uart_add_one_port() has all the information needed to
automatically enable the console device, which is what this patch does.

With this change applied, a device tree platform can be booted without
any console= parameters on the command line and the kernel will still be
able to determine its console.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
---
 drivers/tty/serial/serial_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index ece2049bd270..2fac7593d7b2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -26,6 +26,7 @@
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/console.h>
+#include <linux/of.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <linux/device.h>
@@ -2604,6 +2605,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
 		spin_lock_init(&uport->lock);
 		lockdep_set_class(&uport->lock, &port_lock_key);
 	}
+	if (uport->cons && uport->dev)
+		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
 
 	uart_configure_port(drv, state, uport);
 
-- 
1.8.3.2

[RFC 4/5] arm/versatile: Add the uart as the stdout device.

[Grant Likely]

Signed-off-by: Grant Likely <grant.likely@linaro.org>
---
 arch/arm/boot/dts/versatile-ab.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index e01e5a081def..88e94c5506a1 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -15,6 +15,10 @@
 		i2c0 = &i2c0;
 	};
 
+	chosen {
+		stdout-path = &uart0;
+	};
+
 	memory {
 		reg = <0x0 0x08000000>;
 	};
-- 
1.8.3.2

[RFC 5/5] tty: Update hypervisor tty drivers to use core stdout parsing code.

[Grant Likely]

The evh_bytechan, hvc_opal and hvc_vio drivers all open code the parsing
of the stdout node in the device tree. This patch simplifies the driver
by removing the duplicated functionality.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
---
 drivers/of/base.c          |  5 ++++-
 drivers/tty/ehv_bytechan.c | 43 ++++---------------------------------------
 drivers/tty/hvc/hvc_opal.c | 14 +++-----------
 drivers/tty/hvc/hvc_vio.c  | 29 ++++++++++-------------------
 include/linux/of.h         |  1 +
 5 files changed, 22 insertions(+), 70 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a5643badeb1d..f845fd05d750 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -35,7 +35,7 @@ struct device_node *of_allnodes;
 EXPORT_SYMBOL(of_allnodes);
 struct device_node *of_chosen;
 struct device_node *of_aliases;
-static struct device_node *of_stdout;
+struct device_node *of_stdout;
 
 static struct kset *of_kset;
 
@@ -1956,9 +1956,12 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
 		of_chosen = of_find_node_by_path("/chosen@0");
 
 	if (of_chosen) {
+		/* linux,stdout-path and /aliases/stdout are for legacy compatibility */
 		const char *name = of_get_property(of_chosen, "stdout-path", NULL);
 		if (!name)
 			name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+		if (!name)
+			name = of_get_property(of_aliases, "stdout", NULL);
 		if (name)
 			of_stdout = of_find_node_by_path(name);
 	}
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index 0419b69e270f..4f485e88f60c 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -108,55 +108,23 @@ static void disable_tx_interrupt(struct ehv_bc_data *bc)
  *
  * The byte channel to be used for the console is specified via a "stdout"
  * property in the /chosen node.
- *
- * For compatible with legacy device trees, we also look for a "stdout" alias.
  */
 static int find_console_handle(void)
 {
-	struct device_node *np, *np2;
+	struct device_node *np = of_stdout;
 	const char *sprop = NULL;
 	const uint32_t *iprop;
 
-	np = of_find_node_by_path("/chosen");
-	if (np)
-		sprop = of_get_property(np, "stdout-path", NULL);
-
-	if (!np || !sprop) {
-		of_node_put(np);
-		np = of_find_node_by_name(NULL, "aliases");
-		if (np)
-			sprop = of_get_property(np, "stdout", NULL);
-	}
-
-	if (!sprop) {
-		of_node_put(np);
-		return 0;
-	}
-
 	/* We don't care what the aliased node is actually called.  We only
 	 * care if it's compatible with "epapr,hv-byte-channel", because that
-	 * indicates that it's a byte channel node.  We use a temporary
-	 * variable, 'np2', because we can't release 'np' until we're done with
-	 * 'sprop'.
+	 * indicates that it's a byte channel node.
 	 */
-	np2 = of_find_node_by_path(sprop);
-	of_node_put(np);
-	np = np2;
-	if (!np) {
-		pr_warning("ehv-bc: stdout node '%s' does not exist\n", sprop);
-		return 0;
-	}
-
-	/* Is it a byte channel? */
-	if (!of_device_is_compatible(np, "epapr,hv-byte-channel")) {
-		of_node_put(np);
+	if (!np || !of_device_is_compatible(np, "epapr,hv-byte-channel"))
 		return 0;
-	}
 
 	stdout_irq = irq_of_parse_and_map(np, 0);
 	if (stdout_irq == NO_IRQ) {
-		pr_err("ehv-bc: no 'interrupts' property in %s node\n", sprop);
-		of_node_put(np);
+		pr_err("ehv-bc: no 'interrupts' property in %s node\n", np->full_name);
 		return 0;
 	}
 
@@ -167,12 +135,9 @@ static int find_console_handle(void)
 	if (!iprop) {
 		pr_err("ehv-bc: no 'hv-handle' property in %s node\n",
 		       np->name);
-		of_node_put(np);
 		return 0;
 	}
 	stdout_bc = be32_to_cpu(*iprop);
-
-	of_node_put(np);
 	return 1;
 }
 
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index b01659bd4f7c..0ec1a80dd6a2 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -322,22 +322,14 @@ static void udbg_init_opal_common(void)
 
 void __init hvc_opal_init_early(void)
 {
-	struct device_node *stdout_node = NULL;
+	struct device_node *stdout_node = of_node_get(of_stdout);
 	const __be32 *termno;
 	const char *name = NULL;
 	const struct hv_ops *ops;
 	u32 index;
 
-	/* find the boot console from /chosen/stdout */
-	if (of_chosen)
-		name = of_get_property(of_chosen, "linux,stdout-path", NULL);
-	if (name) {
-		stdout_node = of_find_node_by_path(name);
-		if (!stdout_node) {
-			pr_err("hvc_opal: Failed to locate default console!\n");
-			return;
-		}
-	} else {
+	/* If the console wasn't in /chosen, try /ibm,opal */
+	if (!stdout_node) {
 		struct device_node *opal, *np;
 
 		/* Current OPAL takeover doesn't provide the stdout
diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index b594abfbf21e..5618b5fc7500 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -404,42 +404,35 @@ module_exit(hvc_vio_exit);
 
 void __init hvc_vio_init_early(void)
 {
-	struct device_node *stdout_node;
 	const __be32 *termno;
 	const char *name;
 	const struct hv_ops *ops;
 
 	/* find the boot console from /chosen/stdout */
-	if (!of_chosen)
+	if (!of_stdout)
 		return;
-	name = of_get_property(of_chosen, "linux,stdout-path", NULL);
-	if (name == NULL)
-		return;
-	stdout_node = of_find_node_by_path(name);
-	if (!stdout_node)
-		return;
-	name = of_get_property(stdout_node, "name", NULL);
+	name = of_get_property(of_stdout, "name", NULL);
 	if (!name) {
 		printk(KERN_WARNING "stdout node missing 'name' property!\n");
-		goto out;
+		return;
 	}
 
 	/* Check if it's a virtual terminal */
 	if (strncmp(name, "vty", 3) != 0)
-		goto out;
-	termno = of_get_property(stdout_node, "reg", NULL);
+		return;
+	termno = of_get_property(of_stdout, "reg", NULL);
 	if (termno == NULL)
-		goto out;
+		return;
 	hvterm_priv0.termno = of_read_number(termno, 1);
 	spin_lock_init(&hvterm_priv0.buf_lock);
 	hvterm_privs[0] = &hvterm_priv0;
 
 	/* Check the protocol */
-	if (of_device_is_compatible(stdout_node, "hvterm1")) {
+	if (of_device_is_compatible(of_stdout, "hvterm1")) {
 		hvterm_priv0.proto = HV_PROTOCOL_RAW;
 		ops = &hvterm_raw_ops;
 	}
-	else if (of_device_is_compatible(stdout_node, "hvterm-protocol")) {
+	else if (of_device_is_compatible(of_stdout, "hvterm-protocol")) {
 		hvterm_priv0.proto = HV_PROTOCOL_HVSI;
 		ops = &hvterm_hvsi_ops;
 		hvsilib_init(&hvterm_priv0.hvsi, hvc_get_chars, hvc_put_chars,
@@ -447,7 +440,7 @@ void __init hvc_vio_init_early(void)
 		/* HVSI, perform the handshake now */
 		hvsilib_establish(&hvterm_priv0.hvsi);
 	} else
-		goto out;
+		return;
 	udbg_putc = udbg_hvc_putc;
 	udbg_getc = udbg_hvc_getc;
 	udbg_getc_poll = udbg_hvc_getc_poll;
@@ -456,14 +449,12 @@ void __init hvc_vio_init_early(void)
 	 * backend for HVSI, only do udbg
 	 */
 	if (hvterm_priv0.proto == HV_PROTOCOL_HVSI)
-		goto out;
+		return;
 #endif
 	/* Check whether the user has requested a different console. */
 	if (!strstr(cmd_line, "console="))
 		add_preferred_console("hvc", 0, NULL);
 	hvc_instantiate(0, 0, ops);
-out:
-	of_node_put(stdout_node);
 }
 
 /* call this from early_init() for a working debug console on
diff --git a/include/linux/of.h b/include/linux/of.h
index 417945ebd8e1..1df918ee87d0 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -113,6 +113,7 @@ static inline void of_node_put(struct device_node *node) { }
 extern struct device_node *of_allnodes;
 extern struct device_node *of_chosen;
 extern struct device_node *of_aliases;
+extern struct device_node *of_stdout;
 extern raw_spinlock_t devtree_lock;
 
 static inline bool of_have_populated_dt(void)
-- 
1.8.3.2

Re: [RFC 2/5] of: Create of_console_check() for selecting a console specified in /chosen

[Olof Johansson]

Hi,

On Fri, Mar 28, 2014 at 09:08:02AM -0700, Grant Likely wrote:
> The devicetree has a binding for specifying the console device in the
> /chosen node, but the kernel doesn't use it consistently. This change
> adds an API for testing if a device node is a console, and adds a
> preferred console entry if it is.
> 
> At the same time this patch removes the of_device_is_stdout_path() API
> since it is unused.
> 
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> ---
>  drivers/of/base.c  | 23 +++++++++++++----------
>  include/linux/of.h |  6 +++---
>  2 files changed, 16 insertions(+), 13 deletions(-)

[...]

> diff --git a/include/linux/of.h b/include/linux/of.h
> index a8b9dad90c64..417945ebd8e1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -343,7 +343,7 @@ const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
>   */
>  const char *of_prop_next_string(struct property *prop, const char *cur);
>  
> -int of_device_is_stdout_path(struct device_node *dn);
> +bool of_console_check(struct device_node *dn, char *name, int index);
>  
>  #else /* CONFIG_OF */
>  
> @@ -544,9 +544,9 @@ static inline int of_machine_is_compatible(const char *compat)
>  	return 0;
>  }
>  
> -static inline int of_device_is_stdout_path(struct device_node *dn)
> +static bool of_console_check(const struct device_node *dn, const char *name, int index)

static inline or you'll get warnings about unused functions.


-Olof

Re: [RFC 5/5] tty: Update hypervisor tty drivers to use core stdout parsing code.

[Olof Johansson]

Hi,

On Fri, Mar 28, 2014 at 09:08:05AM -0700, Grant Likely wrote:
> The evh_bytechan, hvc_opal and hvc_vio drivers all open code the parsing
> of the stdout node in the device tree. This patch simplifies the driver
> by removing the duplicated functionality.
> 
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> ---
>  drivers/of/base.c          |  5 ++++-
>  drivers/tty/ehv_bytechan.c | 43 ++++---------------------------------------
>  drivers/tty/hvc/hvc_opal.c | 14 +++-----------
>  drivers/tty/hvc/hvc_vio.c  | 29 ++++++++++-------------------
>  include/linux/of.h         |  1 +
>  5 files changed, 22 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index a5643badeb1d..f845fd05d750 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -35,7 +35,7 @@ struct device_node *of_allnodes;
>  EXPORT_SYMBOL(of_allnodes);
>  struct device_node *of_chosen;
>  struct device_node *of_aliases;
> -static struct device_node *of_stdout;
> +struct device_node *of_stdout;
>  
>  static struct kset *of_kset;
>  
> @@ -1956,9 +1956,12 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
>  		of_chosen = of_find_node_by_path("/chosen@0");
>  
>  	if (of_chosen) {
> +		/* linux,stdout-path and /aliases/stdout are for legacy compatibility */
>  		const char *name = of_get_property(of_chosen, "stdout-path", NULL);
>  		if (!name)
>  			name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> +		if (!name)
> +			name = of_get_property(of_aliases, "stdout", NULL);
>  		if (name)
>  			of_stdout = of_find_node_by_path(name);
>  	}
> diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
> index 0419b69e270f..4f485e88f60c 100644
> --- a/drivers/tty/ehv_bytechan.c
> +++ b/drivers/tty/ehv_bytechan.c
> @@ -108,55 +108,23 @@ static void disable_tx_interrupt(struct ehv_bc_data *bc)
>   *
>   * The byte channel to be used for the console is specified via a "stdout"
>   * property in the /chosen node.
> - *
> - * For compatible with legacy device trees, we also look for a "stdout" alias.
>   */

Did you mean to remove this /aliases/stdout checking? Based on the comment it
seems that some older device trees / platforms might rely on it?

>  static int find_console_handle(void)
>  {
> -	struct device_node *np, *np2;
> +	struct device_node *np = of_stdout;
>  	const char *sprop = NULL;
>  	const uint32_t *iprop;
>  
> -	np = of_find_node_by_path("/chosen");
> -	if (np)
> -		sprop = of_get_property(np, "stdout-path", NULL);
> -
> -	if (!np || !sprop) {
> -		of_node_put(np);
> -		np = of_find_node_by_name(NULL, "aliases");
> -		if (np)
> -			sprop = of_get_property(np, "stdout", NULL);
> -	}
> -
> -	if (!sprop) {
> -		of_node_put(np);
> -		return 0;
> -	}
> -
>  	/* We don't care what the aliased node is actually called.  We only
>  	 * care if it's compatible with "epapr,hv-byte-channel", because that
> -	 * indicates that it's a byte channel node.  We use a temporary
> -	 * variable, 'np2', because we can't release 'np' until we're done with
> -	 * 'sprop'.
> +	 * indicates that it's a byte channel node.
>  	 */
> -	np2 = of_find_node_by_path(sprop);
> -	of_node_put(np);
> -	np = np2;
> -	if (!np) {
> -		pr_warning("ehv-bc: stdout node '%s' does not exist\n", sprop);
> -		return 0;
> -	}
> -
> -	/* Is it a byte channel? */
> -	if (!of_device_is_compatible(np, "epapr,hv-byte-channel")) {
> -		of_node_put(np);
> +	if (!np || !of_device_is_compatible(np, "epapr,hv-byte-channel"))
>  		return 0;
> -	}
>  
>  	stdout_irq = irq_of_parse_and_map(np, 0);
>  	if (stdout_irq == NO_IRQ) {
> -		pr_err("ehv-bc: no 'interrupts' property in %s node\n", sprop);
> -		of_node_put(np);
> +		pr_err("ehv-bc: no 'interrupts' property in %s node\n", np->full_name);
>  		return 0;
>  	}
>  
> @@ -167,12 +135,9 @@ static int find_console_handle(void)
>  	if (!iprop) {
>  		pr_err("ehv-bc: no 'hv-handle' property in %s node\n",
>  		       np->name);
> -		of_node_put(np);
>  		return 0;
>  	}
>  	stdout_bc = be32_to_cpu(*iprop);
> -
> -	of_node_put(np);
>  	return 1;
>  }
>  
> diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
> index b01659bd4f7c..0ec1a80dd6a2 100644
> --- a/drivers/tty/hvc/hvc_opal.c
> +++ b/drivers/tty/hvc/hvc_opal.c
> @@ -322,22 +322,14 @@ static void udbg_init_opal_common(void)
>  
>  void __init hvc_opal_init_early(void)
>  {
> -	struct device_node *stdout_node = NULL;
> +	struct device_node *stdout_node = of_node_get(of_stdout);
>  	const __be32 *termno;
>  	const char *name = NULL;

Name is no longer used, should be removed.

>  	const struct hv_ops *ops;
>  	u32 index;
>  
> -	/* find the boot console from /chosen/stdout */
> -	if (of_chosen)
> -		name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> -	if (name) {
> -		stdout_node = of_find_node_by_path(name);
> -		if (!stdout_node) {
> -			pr_err("hvc_opal: Failed to locate default console!\n");
> -			return;
> -		}
> -	} else {
> +	/* If the console wasn't in /chosen, try /ibm,opal */
> +	if (!stdout_node) {
>  		struct device_node *opal, *np;
>  
>  		/* Current OPAL takeover doesn't provide the stdout


-Olof

Re: [RFC 0/5] of: Automatic console registration cleanups

[Olof Johansson]

On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> Hi all,
> 
> This is a series that I've been playing with over the last few days to
> clean up the selection of default console devices when using the device
> tree. The device tree defines a way of specifying the console by using a
> "stdout-path" property in the /chosen node, but very few drivers
> actually attempt to use that data, and so for most platforms there needs
> to be a "console=" line in the command line if a serial port is intended
> to be used as the console.
> 
> With this series, if there is a /chosen/stdout-path property, and if
> that property points to a serial port node, then when the serial driver
> registers the port, the core uart_add_one_port() function will notice
> and if no console= argument was provided then add it as a preferred
> console.
> 
> I've not tested this very extensively yet, but I want to get some
> feedback before I go further.
> 
> The one downside with this approach is that it doesn't do anything for
> early console setup. That still needs to be added on a per-driver basis,
> but at least it shouldn't conflict with this approach.

Looks sane to me (as discussed in person). I gave it a run on PWRficient with
and without console= line (8250-based uart), and it behaved as expected.

A couple of nits on the series, replied to two of the patches.

I'll give it a run through the board farm here too, but I'll keep console=
bootargs there for those boots at this time, too much to change to take it out
everywhere. :-)


-Olof

Re: [RFC 0/5] of: Automatic console registration cleanups

[Rob Herring]

On Fri, Mar 28, 2014 at 1:56 PM, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
>> Hi all,
>>
>> This is a series that I've been playing with over the last few days to
>> clean up the selection of default console devices when using the device
>> tree. The device tree defines a way of specifying the console by using a
>> "stdout-path" property in the /chosen node, but very few drivers
>> actually attempt to use that data, and so for most platforms there needs
>> to be a "console=" line in the command line if a serial port is intended
>> to be used as the console.
>>
>> With this series, if there is a /chosen/stdout-path property, and if
>> that property points to a serial port node, then when the serial driver
>> registers the port, the core uart_add_one_port() function will notice
>> and if no console= argument was provided then add it as a preferred
>> console.
>>
>> I've not tested this very extensively yet, but I want to get some
>> feedback before I go further.
>>
>> The one downside with this approach is that it doesn't do anything for
>> early console setup. That still needs to be added on a per-driver basis,
>> but at least it shouldn't conflict with this approach.

I'm working on the early aspect. I've got things working with either
command line (which I sent out recently) and with parsing the FDT
(which I haven't sent out yet).

> Looks sane to me (as discussed in person). I gave it a run on PWRficient with
> and without console= line (8250-based uart), and it behaved as expected.
>
> A couple of nits on the series, replied to two of the patches.
>
> I'll give it a run through the board farm here too, but I'll keep console=
> bootargs there for those boots at this time, too much to change to take it out
> everywhere. :-)

It would be good to know if removing console= causes userspace any
issues. For example, if getty's were setup based on console params. I
know ubuntu does some detection of serial ports, but I don't recall
what it looks at. Hopefully it's just checking /dev nodes.

Rob

Re: [RFC 0/5] of: Automatic console registration cleanups

[Christoffer Dall]

On Fri, Mar 28, 2014 at 02:19:23PM -0500, Rob Herring wrote:
> On Fri, Mar 28, 2014 at 1:56 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> >> Hi all,
> >>
> >> This is a series that I've been playing with over the last few days to
> >> clean up the selection of default console devices when using the device
> >> tree. The device tree defines a way of specifying the console by using a
> >> "stdout-path" property in the /chosen node, but very few drivers
> >> actually attempt to use that data, and so for most platforms there needs
> >> to be a "console=" line in the command line if a serial port is intended
> >> to be used as the console.
> >>
> >> With this series, if there is a /chosen/stdout-path property, and if
> >> that property points to a serial port node, then when the serial driver
> >> registers the port, the core uart_add_one_port() function will notice
> >> and if no console= argument was provided then add it as a preferred
> >> console.
> >>
> >> I've not tested this very extensively yet, but I want to get some
> >> feedback before I go further.
> >>
> >> The one downside with this approach is that it doesn't do anything for
> >> early console setup. That still needs to be added on a per-driver basis,
> >> but at least it shouldn't conflict with this approach.
> 
> I'm working on the early aspect. I've got things working with either
> command line (which I sent out recently) and with parsing the FDT
> (which I haven't sent out yet).
> 
> > Looks sane to me (as discussed in person). I gave it a run on PWRficient with
> > and without console= line (8250-based uart), and it behaved as expected.
> >
> > A couple of nits on the series, replied to two of the patches.
> >
> > I'll give it a run through the board farm here too, but I'll keep console=
> > bootargs there for those boots at this time, too much to change to take it out
> > everywhere. :-)
> 
> It would be good to know if removing console= causes userspace any
> issues. For example, if getty's were setup based on console params. I
> know ubuntu does some detection of serial ports, but I don't recall
> what it looks at. Hopefully it's just checking /dev nodes.
> 
In Ubuntu, recent versions at least, it's all just hardcoded in
/etc/init/*.conf files.  The Linaro OE FS does check /proc/cmdline for
console= in there - not sure if we care, or at least we can have it
fixed quickly.

-Christoffer

Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Benjamin Herrenschmidt]

On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote:
> ePAPR 1.1 defines the "stdout-path" property for specifying the console
> device, but Linux currently only handles the older "linux,stdout-path"
> property. This patch adds parsing for the new property name.

Generally a good idea I think, but of course I need time to review and
test ... :-)

One thing that's been annoying me lately with the existing code which
you don't address is ... in a few cases my consoles are usable *VERY*
early. For example PAPR hvc and OPAL hvc can be used before we even turn
the MMU on on powerpc (and thus before we unflatten the device-tree).

It would be nice to be able to have the console going that early,
unfortunately that would imply using the flat device-tree for the
parsing / matching of the stdout-path in those drivers.

Right now, I have this explicit config option to hard wire "early debug"
but there are a few cases of field bugs that can happen in early init
code which I'd like to see logged properly on those systems, and early
debug isn't suitable for field use...

Cheers,
Ben.

Re: [RFC 5/5] tty: Update hypervisor tty drivers to use core stdout parsing code.

[Grant Likely]

On Fri, 28 Mar 2014 11:54:43 -0700, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Mar 28, 2014 at 09:08:05AM -0700, Grant Likely wrote:
> > diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
> > index 0419b69e270f..4f485e88f60c 100644
> > --- a/drivers/tty/ehv_bytechan.c
> > +++ b/drivers/tty/ehv_bytechan.c
> > @@ -108,55 +108,23 @@ static void disable_tx_interrupt(struct ehv_bc_data *bc)
> >   *
> >   * The byte channel to be used for the console is specified via a "stdout"
> >   * property in the /chosen node.
> > - *
> > - * For compatible with legacy device trees, we also look for a "stdout" alias.
> >   */
> 
> Did you mean to remove this /aliases/stdout checking? Based on the comment it
> seems that some older device trees / platforms might rely on it?

I moved it to the common code.

> > diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
> > index b01659bd4f7c..0ec1a80dd6a2 100644
> > --- a/drivers/tty/hvc/hvc_opal.c
> > +++ b/drivers/tty/hvc/hvc_opal.c
> > @@ -322,22 +322,14 @@ static void udbg_init_opal_common(void)
> >  
> >  void __init hvc_opal_init_early(void)
> >  {
> > -	struct device_node *stdout_node = NULL;
> > +	struct device_node *stdout_node = of_node_get(of_stdout);
> >  	const __be32 *termno;
> >  	const char *name = NULL;
> 
> Name is no longer used, should be removed.

Fixed, thanks.

g.

Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Rob Herring]

On Fri, Mar 28, 2014 at 4:33 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote:
>> ePAPR 1.1 defines the "stdout-path" property for specifying the console
>> device, but Linux currently only handles the older "linux,stdout-path"
>> property. This patch adds parsing for the new property name.
>
> Generally a good idea I think, but of course I need time to review and
> test ... :-)
>
> One thing that's been annoying me lately with the existing code which
> you don't address is ... in a few cases my consoles are usable *VERY*
> early. For example PAPR hvc and OPAL hvc can be used before we even turn
> the MMU on on powerpc (and thus before we unflatten the device-tree).
>
> It would be nice to be able to have the console going that early,
> unfortunately that would imply using the flat device-tree for the
> parsing / matching of the stdout-path in those drivers.

I'm working on getting just that working. See my series for "generic
earlycon". I'm working on cleaning up the FDT part still, but have
something functional. The "hardest" part with FDT is doing the address
translation for serial devices, but I just stole that from u-boot.

> Right now, I have this explicit config option to hard wire "early debug"
> but there are a few cases of field bugs that can happen in early init
> code which I'd like to see logged properly on those systems, and early
> debug isn't suitable for field use...

We have the same issue with multi-platform ARM kernels.

Rob

Re: [RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

On Fri, 28 Mar 2014 13:58:36 -0700, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Fri, Mar 28, 2014 at 02:19:23PM -0500, Rob Herring wrote:
> > On Fri, Mar 28, 2014 at 1:56 PM, Olof Johansson <olof@lixom.net> wrote:
> > > On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> > >> Hi all,
> > >>
> > >> This is a series that I've been playing with over the last few days to
> > >> clean up the selection of default console devices when using the device
> > >> tree. The device tree defines a way of specifying the console by using a
> > >> "stdout-path" property in the /chosen node, but very few drivers
> > >> actually attempt to use that data, and so for most platforms there needs
> > >> to be a "console=" line in the command line if a serial port is intended
> > >> to be used as the console.
> > >>
> > >> With this series, if there is a /chosen/stdout-path property, and if
> > >> that property points to a serial port node, then when the serial driver
> > >> registers the port, the core uart_add_one_port() function will notice
> > >> and if no console= argument was provided then add it as a preferred
> > >> console.
> > >>
> > >> I've not tested this very extensively yet, but I want to get some
> > >> feedback before I go further.
> > >>
> > >> The one downside with this approach is that it doesn't do anything for
> > >> early console setup. That still needs to be added on a per-driver basis,
> > >> but at least it shouldn't conflict with this approach.
> > 
> > I'm working on the early aspect. I've got things working with either
> > command line (which I sent out recently) and with parsing the FDT
> > (which I haven't sent out yet).
> > 
> > > Looks sane to me (as discussed in person). I gave it a run on PWRficient with
> > > and without console= line (8250-based uart), and it behaved as expected.
> > >
> > > A couple of nits on the series, replied to two of the patches.
> > >
> > > I'll give it a run through the board farm here too, but I'll keep console=
> > > bootargs there for those boots at this time, too much to change to take it out
> > > everywhere. :-)
> > 
> > It would be good to know if removing console= causes userspace any
> > issues. For example, if getty's were setup based on console params. I
> > know ubuntu does some detection of serial ports, but I don't recall
> > what it looks at. Hopefully it's just checking /dev nodes.
> > 
> In Ubuntu, recent versions at least, it's all just hardcoded in
> /etc/init/*.conf files.  The Linaro OE FS does check /proc/cmdline for
> console= in there - not sure if we care, or at least we can have it
> fixed quickly.

For real hardware using a serial console, I think we want to fix this.
Right my embedded rootfs (buildroot) isn't portable between machines
only because the getty device gets hard coded. /proc/cmdline doesn't
really solve the problem since it doesn't handle non-cmdline selected
consoles. However, /proc/consoles should do the job.

g.

Re: [RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

On Fri, 28 Mar 2014 14:19:23 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Mar 28, 2014 at 1:56 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> >> Hi all,
> >>
> >> This is a series that I've been playing with over the last few days to
> >> clean up the selection of default console devices when using the device
> >> tree. The device tree defines a way of specifying the console by using a
> >> "stdout-path" property in the /chosen node, but very few drivers
> >> actually attempt to use that data, and so for most platforms there needs
> >> to be a "console=" line in the command line if a serial port is intended
> >> to be used as the console.
> >>
> >> With this series, if there is a /chosen/stdout-path property, and if
> >> that property points to a serial port node, then when the serial driver
> >> registers the port, the core uart_add_one_port() function will notice
> >> and if no console= argument was provided then add it as a preferred
> >> console.
> >>
> >> I've not tested this very extensively yet, but I want to get some
> >> feedback before I go further.
> >>
> >> The one downside with this approach is that it doesn't do anything for
> >> early console setup. That still needs to be added on a per-driver basis,
> >> but at least it shouldn't conflict with this approach.
> 
> I'm working on the early aspect. I've got things working with either
> command line (which I sent out recently) and with parsing the FDT
> (which I haven't sent out yet).

Oooh, I missed that. I'll take a look through the series and comment.

g.

Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Grant Likely]

On Sat, 29 Mar 2014 08:33:16 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote:
> > ePAPR 1.1 defines the "stdout-path" property for specifying the console
> > device, but Linux currently only handles the older "linux,stdout-path"
> > property. This patch adds parsing for the new property name.
> 
> Generally a good idea I think, but of course I need time to review and
> test ... :-)
> 
> One thing that's been annoying me lately with the existing code which
> you don't address is ... in a few cases my consoles are usable *VERY*
> early. For example PAPR hvc and OPAL hvc can be used before we even turn
> the MMU on on powerpc (and thus before we unflatten the device-tree).
> 
> It would be nice to be able to have the console going that early,
> unfortunately that would imply using the flat device-tree for the
> parsing / matching of the stdout-path in those drivers.

I think we can get that done. Rob's series goes a long way to that, and
I don't think the flattree parsing will be all that complex.

g.

Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Grant Likely]

On Fri, 28 Mar 2014 16:56:28 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Mar 28, 2014 at 4:33 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote:
> >> ePAPR 1.1 defines the "stdout-path" property for specifying the console
> >> device, but Linux currently only handles the older "linux,stdout-path"
> >> property. This patch adds parsing for the new property name.
> >
> > Generally a good idea I think, but of course I need time to review and
> > test ... :-)
> >
> > One thing that's been annoying me lately with the existing code which
> > you don't address is ... in a few cases my consoles are usable *VERY*
> > early. For example PAPR hvc and OPAL hvc can be used before we even turn
> > the MMU on on powerpc (and thus before we unflatten the device-tree).
> >
> > It would be nice to be able to have the console going that early,
> > unfortunately that would imply using the flat device-tree for the
> > parsing / matching of the stdout-path in those drivers.
> 
> I'm working on getting just that working. See my series for "generic
> earlycon". I'm working on cleaning up the FDT part still, but have
> something functional. The "hardest" part with FDT is doing the address
> translation for serial devices, but I just stole that from u-boot.

:-) There have been several use-cases wanting to property parse reg
properties from the flat tree recently. It would be good to get that as
a generic helper.

g.

Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

[Benjamin Herrenschmidt]

On Fri, 2014-03-28 at 16:56 -0500, Rob Herring wrote:

> I'm working on getting just that working. See my series for "generic
> earlycon". I'm working on cleaning up the FDT part still, but have
> something functional. The "hardest" part with FDT is doing the address
> translation for serial devices, but I just stole that from u-boot.
> 
> > Right now, I have this explicit config option to hard wire "early debug"
> > but there are a few cases of field bugs that can happen in early init
> > code which I'd like to see logged properly on those systems, and early
> > debug isn't suitable for field use...
> 
> We have the same issue with multi-platform ARM kernels.

Ah excellent, I'll keep an eye on it !

Cheers,
Ben.

Re: [RFC 0/5] of: Automatic console registration cleanups

[Sascha Hauer]

On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> Hi all,
> 
> This is a series that I've been playing with over the last few days to
> clean up the selection of default console devices when using the device
> tree. The device tree defines a way of specifying the console by using a
> "stdout-path" property in the /chosen node, but very few drivers
> actually attempt to use that data, and so for most platforms there needs
> to be a "console=" line in the command line if a serial port is intended
> to be used as the console.
> 
> With this series, if there is a /chosen/stdout-path property, and if
> that property points to a serial port node, then when the serial driver
> registers the port, the core uart_add_one_port() function will notice
> and if no console= argument was provided then add it as a preferred
> console.
> 
> I've not tested this very extensively yet, but I want to get some
> feedback before I go further.

I gave it a test on i.MX. It works as expected with both
linux,stdout-path and stdout-path. Specifying a console on the
commandline still works and overrides the devicetree setting.

Tested-by: Sascha Hauer <s.hauer@pengutronix.de>

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

On Mon, 31 Mar 2014 09:10:15 +0200, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> > Hi all,
> > 
> > This is a series that I've been playing with over the last few days to
> > clean up the selection of default console devices when using the device
> > tree. The device tree defines a way of specifying the console by using a
> > "stdout-path" property in the /chosen node, but very few drivers
> > actually attempt to use that data, and so for most platforms there needs
> > to be a "console=" line in the command line if a serial port is intended
> > to be used as the console.
> > 
> > With this series, if there is a /chosen/stdout-path property, and if
> > that property points to a serial port node, then when the serial driver
> > registers the port, the core uart_add_one_port() function will notice
> > and if no console= argument was provided then add it as a preferred
> > console.
> > 
> > I've not tested this very extensively yet, but I want to get some
> > feedback before I go further.
> 
> I gave it a test on i.MX. It works as expected with both
> linux,stdout-path and stdout-path. Specifying a console on the
> commandline still works and overrides the devicetree setting.
> 
> Tested-by: Sascha Hauer <s.hauer@pengutronix.de>

Brilliant! Thanks Sascha.

Can you supply a patch to add stdout to the imx dts files?

g.

Re: [RFC 0/5] of: Automatic console registration cleanups

[Sascha Hauer]

On Mon, Mar 31, 2014 at 10:41:24AM +0100, Grant Likely wrote:
> On Mon, 31 Mar 2014 09:10:15 +0200, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> > > Hi all,
> > > 
> > > This is a series that I've been playing with over the last few days to
> > > clean up the selection of default console devices when using the device
> > > tree. The device tree defines a way of specifying the console by using a
> > > "stdout-path" property in the /chosen node, but very few drivers
> > > actually attempt to use that data, and so for most platforms there needs
> > > to be a "console=" line in the command line if a serial port is intended
> > > to be used as the console.
> > > 
> > > With this series, if there is a /chosen/stdout-path property, and if
> > > that property points to a serial port node, then when the serial driver
> > > registers the port, the core uart_add_one_port() function will notice
> > > and if no console= argument was provided then add it as a preferred
> > > console.
> > > 
> > > I've not tested this very extensively yet, but I want to get some
> > > feedback before I go further.
> > 
> > I gave it a test on i.MX. It works as expected with both
> > linux,stdout-path and stdout-path. Specifying a console on the
> > commandline still works and overrides the devicetree setting.
> > 
> > Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> Brilliant! Thanks Sascha.
> 
> Can you supply a patch to add stdout to the imx dts files?

The information which console is used on each board is not in the
kernel. I can create a patch adding stdout for a handful of boards I
know, but I won't catch all.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

On Tue, 1 Apr 2014 08:12:16 +0200, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Mar 31, 2014 at 10:41:24AM +0100, Grant Likely wrote:
> > On Mon, 31 Mar 2014 09:10:15 +0200, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > On Fri, Mar 28, 2014 at 09:08:00AM -0700, Grant Likely wrote:
> > > > Hi all,
> > > > 
> > > > This is a series that I've been playing with over the last few days to
> > > > clean up the selection of default console devices when using the device
> > > > tree. The device tree defines a way of specifying the console by using a
> > > > "stdout-path" property in the /chosen node, but very few drivers
> > > > actually attempt to use that data, and so for most platforms there needs
> > > > to be a "console=" line in the command line if a serial port is intended
> > > > to be used as the console.
> > > > 
> > > > With this series, if there is a /chosen/stdout-path property, and if
> > > > that property points to a serial port node, then when the serial driver
> > > > registers the port, the core uart_add_one_port() function will notice
> > > > and if no console= argument was provided then add it as a preferred
> > > > console.
> > > > 
> > > > I've not tested this very extensively yet, but I want to get some
> > > > feedback before I go further.
> > > 
> > > I gave it a test on i.MX. It works as expected with both
> > > linux,stdout-path and stdout-path. Specifying a console on the
> > > commandline still works and overrides the devicetree setting.
> > > 
> > > Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > Brilliant! Thanks Sascha.
> > 
> > Can you supply a patch to add stdout to the imx dts files?
> 
> The information which console is used on each board is not in the
> kernel. I can create a patch adding stdout for a handful of boards I
> know, but I won't catch all.

That's all I'm asking for. I don't expect all platforms.

g.

Re: [RFC 0/5] of: Automatic console registration cleanups

[Rob Herring]

On Fri, Mar 28, 2014 at 11:08 AM, Grant Likely <grant.likely@linaro.org> wrote:
> Hi all,
>
> This is a series that I've been playing with over the last few days to
> clean up the selection of default console devices when using the device
> tree. The device tree defines a way of specifying the console by using a
> "stdout-path" property in the /chosen node, but very few drivers
> actually attempt to use that data, and so for most platforms there needs
> to be a "console=" line in the command line if a serial port is intended
> to be used as the console.
>
> With this series, if there is a /chosen/stdout-path property, and if
> that property points to a serial port node, then when the serial driver
> registers the port, the core uart_add_one_port() function will notice
> and if no console= argument was provided then add it as a preferred
> console.
>
> I've not tested this very extensively yet, but I want to get some
> feedback before I go further.
>
> The one downside with this approach is that it doesn't do anything for
> early console setup. That still needs to be added on a per-driver basis,
> but at least it shouldn't conflict with this approach.

Hey, what happened with this series?

Rob

Re: [RFC 0/5] of: Automatic console registration cleanups

[Grant Likely]

On Wed, 11 Jun 2014 20:28:31 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Mar 28, 2014 at 11:08 AM, Grant Likely <grant.likely@linaro.org> wrote:
> > Hi all,
> >
> > This is a series that I've been playing with over the last few days to
> > clean up the selection of default console devices when using the device
> > tree. The device tree defines a way of specifying the console by using a
> > "stdout-path" property in the /chosen node, but very few drivers
> > actually attempt to use that data, and so for most platforms there needs
> > to be a "console=" line in the command line if a serial port is intended
> > to be used as the console.
> >
> > With this series, if there is a /chosen/stdout-path property, and if
> > that property points to a serial port node, then when the serial driver
> > registers the port, the core uart_add_one_port() function will notice
> > and if no console= argument was provided then add it as a preferred
> > console.
> >
> > I've not tested this very extensively yet, but I want to get some
> > feedback before I go further.
> >
> > The one downside with this approach is that it doesn't do anything for
> > early console setup. That still needs to be added on a per-driver basis,
> > but at least it shouldn't conflict with this approach.
> 
> Hey, what happened with this series?

Ummm... I got distracted and forgot about it? I merged the first patch
that adds stdout-path parsing, but the rest are still sitting in a side
branch. I'll dust them off and rebase onto current mainline.

g.