Re: [PATCH 3/3] UIO: generic platform driver

[Uwe Kleine-König]

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@xxxxxxxx>
> > > ---
> > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/