Grant Likely wrote:
So, seeing as settling on a way to determine stdout still up in the air,
it probably makes sense to condense that code down to a single
authoritative function so that changes in this area are contained in one
place. For now, I'll stick with decoding linux,stdout-path and on
On Thu, Aug 07, 2008 at 04:12:54PM +1000, David Gibson wrote:
On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device
On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of David Gibson
Sent: Thursday, August 07, 2008 1:13 AM
To: Tabi Timur
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout
Yoder Stuart wrote:
The second was the idea that we may need a /aliases/stdin as well.
You could conceptually have stdout be a monitor and a stdin
be a keyboard.
I don't think the hypervisor console subsystem supports this. I don't see any
way of registering separate clients for input vs.
TimurTabi wrote:
Yoder Stuart wrote:
The second was the idea that we may need a
/aliases/stdin as well. You could conceptually have
stdout be a monitor and a stdin be a keyboard.
I don't think the hypervisor console subsystem supports
this. I don't see any way of registering separate
Milton Miller wrote:
Why should what the hvc driver support have any effect on
what the binding should be?
Because my hypervisor console driver uses the hypervisor console/tty subsystem.
If the subsystem assumes one stdout/stdin device, then I must abide by that.
--
Timur Tabi
Linux kernel
Timur Tabi wrote:
Milton Miller wrote:
Why should what the hvc driver support have any effect on
what the binding should be?
Because my hypervisor console driver uses the hypervisor console/tty subsystem.
If the subsystem assumes one stdout/stdin device, then I must abide by that.
So fix
On Wed, 2008-08-06 at 00:35 -0600, Grant Likely wrote:
On Wed, Aug 6, 2008 at 12:32 AM, David Miller [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
Date: Wed, 06 Aug 2008 00:02:44 -0600
of_lookup_stdout() is useful for figuring out what device to use as output
for early
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not familiar enough with real
On Wed, 2008-08-06 at 11:46 -0500, Timur Tabi wrote:
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the chosen node.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the chosen node.
From: Grant Likely [EMAIL PROTECTED]
Date: Wed, 06 Aug 2008 00:02:44 -0600
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the chosen node.
Signed-off-by: Grant
On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
[EMAIL PROTECTED] wrote:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the
On Wed, Aug 6, 2008 at 12:32 AM, David Miller [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
Date: Wed, 06 Aug 2008 00:02:44 -0600
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
From: Grant Likely [EMAIL PROTECTED]
Date: Wed, 6 Aug 2008 00:35:24 -0600
On Wed, Aug 6, 2008 at 12:32 AM, David Miller [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
Date: Wed, 06 Aug 2008 00:02:44 -0600
of_lookup_stdout() is useful for figuring out what device to use as
Hi Grant,
On Wed, 6 Aug 2008 00:34:04 -0600 Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
[EMAIL PROTECTED] wrote:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Wed, 6 Aug 2008 17:42:33 +1000
Hi Grant,
On Wed, 6 Aug 2008 00:34:04 -0600 Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
[EMAIL PROTECTED] wrote:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely
On Wed, 6 Aug 2008 17:42:33 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote:
Could you also send an email to Dave Miller to see if he has any objections
to this function being generic (since the Sparc guys share this code).
So I should read ahead :-)
--
Cheers,
Stephen Rothwell
David Miller writes:
On sparc platforms this is obtained differently. We obtain the 32-bit
instance value of /chosen/stdout and convert that into a prom device
node path using instance-to-path.
That's actually exactly what we do too, the linux,stdout-path property
is just a cache of the
From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 6 Aug 2008 20:21:04 +1000
David Miller writes:
On sparc platforms this is obtained differently. We obtain the 32-bit
instance value of /chosen/stdout and convert that into a prom device
node path using instance-to-path.
That's
On Wed, Aug 6, 2008 at 4:21 AM, Paul Mackerras [EMAIL PROTECTED] wrote:
David Miller writes:
On sparc platforms this is obtained differently. We obtain the 32-bit
instance value of /chosen/stdout and convert that into a prom device
node path using instance-to-path.
That's actually exactly
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not familiar enough with real OF to
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote:
From: Grant Likely [EMAIL PROTECTED]
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the
Segher Boessenkool wrote:
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not
On Wed, Aug 06, 2008 at 06:25:48PM +0200, Segher Boessenkool wrote:
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt
27 matches
Mail list logo
