Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 Sparc decoding the ihandle with the expectation that there will be further refinements to be made. Ack. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 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. > > > > I thought linux,stdout-path is deprecated are we're supposed to be > > using the aliases node instead? > > During the ePAPR process this idea came up - standardising a 'stdout' > alias that would replace linux,stdout-path in chosen. However that > was done in ignorance of the history of the linux,stdout-path property > and its connection to the stdout ihandle in chosen. In any case, the > proposed 'stdout' alias didn't make the final cut for ePAPR, so how to > address this for flat-tree systems is still an open question. 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 Sparc decoding the ihandle with the expectation that there will be further refinements to be made. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 pointed to by the > > linux,stdout-path property in the chosen node. > > I thought linux,stdout-path is deprecated are we're supposed to be > using the aliases node instead? You are mixing two completely different things afaik. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
> 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 > know the answer. I'm assuming that an instance value is not the same > as a phandle). Yup, there are two issues there: - The instance value would have to be converted to a phandle while OF is still alive. I initially did that and added a stdout-node or so property, but that still hit the next issue. - IBM machines has this weird distinction between the real phandle and the ibm,phandle, the later being the same except for things that get hotplugged ... and some of the vdevices. We got really confused trying to sort that out with the output device. So in the end, I decided to just convert the ihandle to a path and stick that path in the device-tree. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 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 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". > > How about if I modify it to try both methods? The sparc method however cannot be used on powerpc because it requires a call to OF to do the "live" conversion (ie, instance-to-path). In fact, our /chosen/linux,stdout-path is just a cached result of that conversion done during boot. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 the subsystem, don't use the subsystem, or live with the fact that you support a subset of what the device tree can express. Don't cripple the device tree because of that. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 clients > for input vs. output. Why should what the hvc driver support have any effect on what the binding should be? And anyways, both the boot wrapper and udbg (and hence early debug console) have totally indepenedent functions for reading and writing. And for that matter, we also support output on monitor and input on keyboard for linear frame buffer on 6xx via the btext output (but only adb input). milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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. output. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
> -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() > utility function > > 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 the node > pointed to by the > > > linux,stdout-path property in the chosen node. > > > > I thought linux,stdout-path is deprecated are we're supposed to be > > using the aliases node instead? > > During the ePAPR process this idea came up - standardising a 'stdout' > alias that would replace linux,stdout-path in chosen. However that > was done in ignorance of the history of the linux,stdout-path property > and its connection to the stdout ihandle in chosen. In any case, the > proposed 'stdout' alias didn't make the final cut for ePAPR, so how to > address this for flat-tree systems is still an open question. In the ePAPR discussion I think we generally agreed that an alias was better than a property under /chosen. There were 2 things that caused us to delete the /aliases/stdout. One was discussions around whether we needed to support multiple consoles somehow. 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. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 the node pointed to by the > > linux,stdout-path property in the chosen node. > > I thought linux,stdout-path is deprecated are we're supposed to be > using the aliases node instead? During the ePAPR process this idea came up - standardising a 'stdout' alias that would replace linux,stdout-path in chosen. However that was done in ignorance of the history of the linux,stdout-path property and its connection to the stdout ihandle in chosen. In any case, the proposed 'stdout' alias didn't make the final cut for ePAPR, so how to address this for flat-tree systems is still an open question. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 blobs >> use /chosen/stdout also? (I'm not familiar enough with real OF to >> know the answer. I'm assuming that an instance value is not the same >> as a phandle). > > ihandles and phandles are not the same thing in OF. Since in the > "flat world" we cannot have instances, we should use phandles instead > of ihandles for the things in /chosen. I thought we agreed on that > already, perhaps I am wrong? Not that I recall. In general we've been avoiding using anything that traditionally contains an ihandle; hence the direct use of linux,stdout-path when using a flat tree. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). The difference between a phandle and an ihandle is similar to the difference between (the inode of) an executable files on disk and (the process id of) a running process. A phandle refers to the static information that describes a device, while an ihandle refers to a particular (out of potentially several) active instantiation of the OFW driver for that devices. An "instance value" is a data item that can have a different value for each of the running instances of a given driver. In the analogy, an instance value is like a data segment variable. Given an ihandle, you can get the corresponding phandle with ihandle>phandle. You can't go from phandle to ihandle, because that direction is one-to-many. Why you you ever need more than one running instance of a given driver? For leaf devices, it is pretty rare to have multiple instances. Multiple instances are more often used for intermediate nodes. The same intermediate node - for example a usb node - is often the parent of several leaf nodes that are active simultaneously. When you open a device, its device tree parents up to the root are implicitly opened. Each such instance can hold dynamic state on behalf of its children. ihandles and phandles are not the same thing in OF. Since in the "flat world" we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Segher ___ devicetree-discuss mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 chosen node. I thought linux,stdout-path is deprecated are we're supposed to be using the aliases node instead? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 know the answer. I'm assuming that an instance value is not the same as a phandle). ihandles and phandles are not the same thing in OF. Since in the "flat world" we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 what we do too, the linux,stdout-path property > is just a cache of the result of that process. The difference is that > we have to do it early on while we still have OF around, while you can > do it later. 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 know the answer. I'm assuming that an instance value is not the same as a phandle). g. > > Paul. > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 actually exactly what we do too, the linux,stdout-path property > is just a cache of the result of that process. The difference is that > we have to do it early on while we still have OF around, while you can > do it later. I do it right when I build the in-kernel OBP tree. Then I cache these results in: extern struct device_node *of_console_device; extern char *of_console_path; extern char *of_console_options; which are declared in asm/prom.h I could compute it even earlier and just store a phandle instead of a device_node pointer. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 result of that process. The difference is that we have to do it early on while we still have OF around, while you can do it later. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpinAKqgbXKd.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 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. > > > > > > Nice. You don't feel like converting all the places that currently do it > > > by hand to use this do you :) > > > > Yep, I'll do this. :-) > > 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). I already voiced my concerns. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 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. > > > > Nice. You don't feel like converting all the places that currently do it > > by hand to use this do you :) > > Yep, I'll do this. :-) 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). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpyGyJkll8RU.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 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 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". > > How about if I modify it to try both methods? Sure, that would be nice. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 >> linux,stdout-path property in the chosen node. >> >> Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > 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". How about if I modify it to try both methods? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 node pointed to by the >> linux,stdout-path property in the chosen node. > > Nice. You don't feel like converting all the places that currently do it > by hand to use this do you :) Yep, I'll do this. :-) g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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 Likely <[EMAIL PROTECTED]> 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". If this of_lookup_stdout() is going into generic OF code, it should be done in a way that works on all platforms. All of these "linux,*" properties and node names are powerpc platform specific. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
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. Nice. You don't feel like converting all the places that currently do it by hand to use this do you :) cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
