[UPSTREAM - RFC] pcf50633_use_regulator_api.patch

Balaji Rao balaji at raobalaji.com
Thu Oct 9 04:00:14 CEST 2008


On Thu, 9 Oct 2008 00:15:07 +0200
Harald Welte <laforge at openmoko.org> wrote:

> Dear Balaji,
> 
> first of all thanks for all your work.
> 
Hi Harald,

You are welcome.

> However:
> 
> On Wed, Oct 08, 2008 at 07:38:45PM +0530, Balaji Rao wrote:
> > pcf50633_use_regulator_api.patch
> 
> I don't really like the split betwee the i2c-pcf5633 part and the
> regulator part.  It means that you need to publicly expose/export a
> number of low level register read/write/set/clearbit functions, plus
> put the entire register definitions into the public linux/pcf50633.h
> file.
> 
> It is usually not a good idea to expose that many internal details to
> the kernel.  Either you just put the two files into one driver by
> directly linking multiple .c/.o files into one .ko, or you find some
> other way how to find a high-level API between the two drivers.
> 
> I personally think putting the i2c and the regulator bits together is
> a good idea.
> 

We had discussed it a bit on which approach to take. Apparently, both
have their own advantages.

Mark had expressed his feeling that as a subsystem maintainer he would
prefer that things are separated. The counter argument to this would
be that say, the pcf50633 regulator wouldn't be used by anyone other
than us and there's no point in separating it. Both seem right :)

Also, the sm501 driver in the kernel, which lives in drivers/mfd and
say, the sm501 ohci controller that lives in drivers/usb/host are
separate. Since this is already accepted upstream, I thought it might
help us get this code accepted and it's also the biggest reason I'm
slightly inclined to this approach.

I'm still not sure. It's highly debatable. I'd be happy be some more
discussion so that we come to a uniform conclusion.

	- Balaji



More information about the openmoko-kernel mailing list