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
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 retu
> 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 r
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
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 t
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
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 registerin
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.
> -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]
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.
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 t
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 famil
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
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
kn
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 ac
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".
>
>
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 th
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
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 -0
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
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
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
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 r
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:
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.
26 matches
Mail list logo
