[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100816002244.6ddf37e6@debxo>
Date: Mon, 16 Aug 2010 00:22:44 -0400
From: Andres Salomon <dilinger@...ued.net>
To: David Miller <davem@...emloft.net>
Cc: grant.likely@...retlab.ca, devicetree-discuss@...ts.ozlabs.org,
sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] sparc: make driver/of/pdt no longer sparc-specific
On Sun, 08 Aug 2010 22:34:44 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:
> From: Andres Salomon <dilinger@...ued.net>
> Date: Mon, 9 Aug 2010 01:32:45 -0400
>
> > On Sun, 8 Aug 2010 23:12:21 -0600
> > Grant Likely <grant.likely@...retlab.ca> wrote:
> >
> >> If you have to explicitly cast these function pointers, then you're
> >> doing it wrong. :-) Listen to and fix the compiler complaint
> >> here.
> >>
> >
> > Hm, can you please expand on that? The reason it's necessary to
> > cast is because sparc's prom_* functions are using ints instead of
> > phandles. I don't understand why casting is the wrong thing here.
> >
> > I could write some 1-line wrapper functions that simply call prom_*
> > rather than casting, I suppose.
>
> There's no reason the Sparc interfaces can't take phandles since they
> are just ints, and that would make the call signatures of these
> functions compatible with the types used by the other architectures.
You're saying to convert the sparc code to use phandles? Doing so has
caused phandles to show up in asm/openprom.h (linux_dev_v2_funcs's
v2_inst2pkg returns a phandle, and linux_nodeops use phandles). This
is fine, except asm/openprom.h is an exported kernel header, and
linux/of.h is not.
I'm tempted to break the phandle/device_node/property stuff out into a
separate header (that gets exported), and include that from linux/of.h
and asm/openprom.h.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists