new kernel ... / meaning of stable-tracking

Andy Green andy at
Wed Sep 24 08:34:47 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Monday 22 September 2008 08:16:34 pm Werner Almesberger wrote:
| <snip>
|> I think it would be nice if the PCF50633 driver (~2700 lines) could
|> be broken down into its functional parts, e.g., regulators, RTC,
|> charger, and so on, also because this would make it clearer which
|> part needs which API. For example, the regulators don't care about
|> RTC, yet they "see" the API because they're in the same file with
|> the RTC part.
| Seperating the RTC is straightforward i guess. The regulators too have
| their own ABI to be exported via sysfs and it looks like we've to
| change quite a bit of code to do it.

If there are equivalents exposed by the platform stuff elsewhere, it's
OK if we move stuff in sysfs to get the job done and break userspace.
We are doing it to improve the driver, get code upstream and we will
only introduce it when we are ready as a major update to 2.6.28 or
whatever so there will be plenty of time for userspace to catch up.

| What are the other parts that we need to seperate out ? Do we need to
| provide sysfs interfaces for , say led control and charger ?

Generally we have to be pragmatic and focus on code that does something
on our devices.  We are not NXP, so it's not in our interests to spend
ages filling out every single feature of that chip with beautifully
crafted code whether we use it or not, what is in our interests is to do
a good job on the areas we are using or see ourselves use in near future
so it makes a product we can sell to customers.

Practically, we can't test the features we don't use either (and that
testing problem applies to whole pcf50606 as well, it was only used in

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list