[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081216131849.GA30249@linux-sh.org>
Date: Tue, 16 Dec 2008 22:18:49 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Wolfram Sang <w.sang@...gutronix.de>
Cc: hjk@...utronix.de, gregkh@...e.de, linux-kernel@...r.kernel.org,
linuxppc-dev@...abs.org, magnus.damm@...il.com
Subject: Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Tue, Dec 16, 2008 at 01:41:56PM +0100, Wolfram Sang wrote:
> > In addition to the stuff pointed out by Greg, I don't see what you
> > actually gain by hacking the OF crap in to this driver. You would be
> > better off layering the OF driver on top of this, rather than trying to
> > make them live together in the same file.
> >
> > See pata_platform/pata_of_platform for an example of how to do this a bit
> > more sanely.
>
> See my reply just posted. I found two ways to go, and from reading
> discussions on the lists, finally decided for this way. May have been
> the wrong path, but nothing that could not be changed.
>
I guess there are a couple of things to consider. If it fits in fairly
nicely and can be optimized out for the users that don't care, then
integration generally makes sense. In this case however you have a large
and insular block that is ifdef'ed in and selected by Kconfig, suggesting
that the only benefit is for your driver which wishes to tie in to parts
of uio_pdrv_genirq, with there being no benefits the other way. This sort
of situation suggests you are better off layering and simply exposing the
functionality you need from uio_pdrv_genirq. This was certainly the case
with pata_platform as well, and it worked out pretty well there compared
to hacking it in-place.
--
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