On Fri, Aug 24, 2007 at 09:48:37AM -0500, Scott Wood wrote:
> On Fri, Aug 24, 2007 at 11:01:22AM +1000, David Gibson wrote:
> > On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> > > It's likely to be ugly no matter what, though I'll try to come up with
> > > something slightly nicer.
On Fri, Aug 24, 2007 at 11:01:22AM +1000, David Gibson wrote:
> On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> > It's likely to be ugly no matter what, though I'll try to come up with
> > something slightly nicer. If I were doing this code from scratch, I'd
> > probably liven the
On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> David Gibson wrote:
> > Actually, no - sorry, that's the other problem with this, which I
> > forgot to mention. On real OF, the "name" property contains the
> > node's name *without the unit address*; that is, only the portion
> > befo
> Actually, in any case, I don't think we want to implement get_path()
> this way for real OF. Better to have get_path() itself as a callback:
> on real OF I believe we can directly ask for the full path to a given
> phandle,
Yes. "package-to-path" from the client interface.
Segher
__
David Gibson wrote:
> Actually, no - sorry, that's the other problem with this, which I
> forgot to mention. On real OF, the "name" property contains the
> node's name *without the unit address*; that is, only the portion
> before the '@'. So your getprop change does not match real OF
> behaviour
On Wed, Aug 22, 2007 at 12:24:56PM -0500, Scott Wood wrote:
> On Wed, Aug 22, 2007 at 11:09:07AM +1000, David Gibson wrote:
> > On Tue, Aug 21, 2007 at 11:09:58AM -0500, Scott Wood wrote:
> > > The point of #2 was as part of the fix to #1 -- otherwise, the same
> > > check for NULL would have to b
On Wed, Aug 22, 2007 at 11:09:07AM +1000, David Gibson wrote:
> On Tue, Aug 21, 2007 at 11:09:58AM -0500, Scott Wood wrote:
> > The point of #2 was as part of the fix to #1 -- otherwise, the same
> > check for NULL would have to be moved into ft_create_node to
> > conditionally call ft_find_devic
On Tue, Aug 21, 2007 at 11:09:58AM -0500, Scott Wood wrote:
> David Gibson wrote:
> > On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote:
> >
> >>1. ft_create_node was returning the internal pointer rather than a phandle.
> >>2. ft_find_device_rel was treating a "top" phandle of NULL as an
David Gibson wrote:
> On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote:
>
>>1. ft_create_node was returning the internal pointer rather than a phandle.
>>2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
>>rather than as the root of the tree.
>>3. Return the node's
On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote:
> 1. ft_create_node was returning the internal pointer rather than a phandle.
> 2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
> rather than as the root of the tree.
> 3. Return the node's name when getprop() is ca
1. ft_create_node was returning the internal pointer rather than a phandle.
2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
rather than as the root of the tree.
3. Return the node's name when getprop() is called with the "name" property.
Signed-off-by: Scott Wood <[EMAIL PR
11 matches
Mail list logo
