Messages in this thread | | | Date | Tue, 20 May 2008 11:23:12 +0200 | From | Uwe Kleine-König <> | Subject | Re: [PATCH 3/3] UIO: generic platform driver |
| |
Hello Hans,
Hans J. Koch wrote: > On Wed, Apr 23, 2008 at 10:56:29AM +0200, Uwe Kleine-König wrote: > > Hello, > > > > Uwe Kleine-König wrote: > > > Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> > > > --- > > > Hello, > > > > > > This is the former patch 4/4 after some discussion. > > > > > > Open issues: > > > - clock name "uio" isn't considered good by Russell King > > > I don't have a better suggestion > > I added another branch[1] on my repo that doesn't have the dummy clk > > patch and variant of this one that doesn't use the clk API. > > > > This way the clk API isn't needed anymore for my patch and the issue > > about the clock name disappeard, too. > > Hi Uwe, > sorry for the delay, I was away for a few days and had an awful lot of > work when I came back. > > About your generic platform driver: I think we've got two choices, both > of them are acceptable as far as I'm concerned: > > 1.) Use the clk API and make your driver depend on it. AFAICS, only ARM > and PPC implement it right now. On some platforms, it will probably > never be implemented. E.g. x86 doesn't have any clocks that could be > controlled that way. It's probably only useful for SoCs. > Advantages: People who need it get clk support for free, without having > to write much code. > Disadvantages: The generic platform driver is not available for all > platforms. It might not be easy to implement the dependency in Kconfig > in a way acceptable to all maintainers ;-) > > 2.) Don't use the clk API. I don't think we would lose much. Drivers > could implement clk stuff in their board support. You could add some > generic function pointers in struct uio_platdata that are called in > open/release/probe/remove. That way, any platform specific stuff, > including clk, could be handled. > Advantages: The generic platform driver is available for all > platforms, no need for dependencies in Kconfig. > Disadvantages: People who need clk_* must write a lot of code within > their board support file. Not nice and clean... > > I'm ready to accept 1.) or 2.), or even both of them (why can't we have > two generic platform drivers?) For now I suggest 2). Using the clk API might be implemented by a generic open/release routine. Maybe I will look into that at a later time. For now I'm happy without clk support, too.
For now you can find two patches in my uio branch at git://www.modarm9.com/gitsrc/pub/people/ukleinek/linux-2.6.git uio
I rebased them to current Linus' master; otherwise they are unmodified since the last posts. For completeness I'll resend them as a reply to this mail.
For shortlog and diffstat see below.
Best regards Uwe
Uwe Kleine-König (2): UIO: don't let UIO_CIF and UIO_SMX depend twice on UIO UIO: generic platform driver
drivers/uio/Kconfig | 10 +++- drivers/uio/Makefile | 1 + drivers/uio/uio_pdrv.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 127 insertions(+), 2 deletions(-)
-- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |