On Wed, 2007-10-03 at 08:39 -0600, Grant Likely wrote:
> Right, okay. Looking at platform_device_add(), the default parent is
> platform_bus, but it can be overridden. of_platform_bus devices get
> the hierarchy of the device tree by default. So in the platform bus
> case, the constructor would
On 10/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 22:18 -0600, Grant Likely wrote:
>
> > For many drivers, I think that is already the case. USB OHCI is a
> > prime example where there are both PCI and platform_bus bindings among
> > others. It seems to me th
On Tue, 2007-10-02 at 22:18 -0600, Grant Likely wrote:
> For many drivers, I think that is already the case. USB OHCI is a
> prime example where there are both PCI and platform_bus bindings among
> others. It seems to me that the bus binding effectively translates
> down to "where do I go to ge
On 10/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > My opinion is that since it is driver-specific code anyway, then it
> > belongs with the driver. Plus a driver writer for ARM doesn't need to
> > write them. It's the powerpc or microblaze developer who will do it.
> > If the dri
> My opinion is that since it is driver-specific code anyway, then it
> belongs with the driver. Plus a driver writer for ARM doesn't need to
> write them. It's the powerpc or microblaze developer who will do it.
> If the driver maintainer doesn't want the binding in the main driver
> .c file, t
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes:
Grant> From: Grant Likely <[EMAIL PROTECTED]> Add of_platform
Grant> bus binding so this driver can be used with arch/powerpc
Grant> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: Peter Korsgaard <[EMAIL PROTECTED]>
--
Bye
On 10/2/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> It would be nice, though, to merge platform and of_platform to some
> extent, so that things which don't need to check "special" device tree
> properties wouldn't have to make any changes other than maybe adding an
> extra match table entry.
yes,
On 10/2/07, Peter Korsgaard <[EMAIL PROTECTED]> wrote:
> > "Grant" == Grant Likely <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> Grant> static int __devinit
> Grant> ulite_of_probe(struct of_device *op, const struct of_device_id *match)
>
> This looks like uartlite code to me ;)
>
> Grant> {
> Gr
Peter Korsgaard wrote:
> Grant> What advantages do you see with the constructor approach?
>
> One advantage is that it keeps the of stuff out of the drivers. There
> already is one bus for platform stuff in the kernel, so from a device
> driver writer POV the of stuff is just extra fluff. Imagine
> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes:
Hi,
Grant> static int __devinit
Grant> ulite_of_probe(struct of_device *op, const struct of_device_id *match)
This looks like uartlite code to me ;)
Grant> {
Grant> struct resource res;
Grant> const unsigned int *id;
On 10/1/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-30 at 16:42 -0600, Grant Likely wrote:
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > Add of_platform bus binding so this driver can be used with arch/powerpc
>
> Another option is to have a "constructor" in the p
On Sun, 2007-09-30 at 16:42 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Add of_platform bus binding so this driver can be used with arch/powerpc
Another option is to have a "constructor" in the platform code that
generates the platform device from the DT. It might eve
From: Grant Likely <[EMAIL PROTECTED]>
Add of_platform bus binding so this driver can be used with arch/powerpc
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 101 +
1 files changed, 93 insertions(+), 8 deletions(-)
13 matches
Mail list logo
