linux-kernel - Re: [PATCH 3/3] UIO: generic platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Apr 2008 19:12:01 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
Cc:	"Hans J. Koch" <hjk@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] UIO: generic platform driver

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@...i.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?)

As you are the author (and probably user) of this driver, please decide,
and send a new patch for review.

Thanks,
Hans

--
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/