new kernel ... / meaning of stable-tracking

[Werner Almesberger]

Andy Green wrote:
> What I think I would suggest is to go through the steps we talked about
> already to form a clean add-pcf50633-support-to-mainline.patch, and then
> approach upstream with it explaining the situation as an RFC about what
> absolutely has to be changed.

By the way, if introducing new APIs and the like, they should come in
a separate patch. E.g., a typical patch sequence for a new component
may look like this:

[PATCH 0/n] Description of foo and of the patches that follow
[PATCH a/n] New APIs
[PATCH b/n] New general code
[PATCH c/n] Changes to existing APIs
[PATCH d/n] Changes to existing general code
[PATCH e/n] The actual driver, broken down into component patches
[PATCH f/n] Platform-specific code (if any)

Each item here may consist of multiple patches. One thing that's
importent is that the patches must be bisectable, i.e., one must be
able to stop at any point in this patch sequence, and still get a
kernel that builds and doesn't crash.

(This is because people use git-bisect to search for regressions.
Even if the search is completely unrelated to our code, git-bisect
may just happen to place the cut anywhere in our patch sequence.)

E.g., this often means that Makefile and Kconfig changes go last, so
if the driver consists of foo.c and bar.c in separate patches, no
build problems result if foo.c is applied but bar.c is not (yet).

The example above is of course a bit exaggerated. If you have to
introduce a new API, you'd probably stop at b/n or d/n, and enter
the discussion, maybe keeping the other code to illustrate how that
API is used.

> Maybe they have mercy about regulator API
> because we are nice guys, we dunno.  Then discuss the results of it on
> this list and we figure out what to do.

You mean include/linux/pcf506xx.h ? That's only the tip of the
iceberg. Most of the real API is PCF50633-specific.

Of course, PCF50633 links into a lot of other APIs: I2C, backlight,
RTC, and APM. (Did I forget any ?) And it makes heavy use of sysfs
and a bit of input events. But little of this is abstracted from the
actual PCF50633.

It's indeed an interesting question whether we should try to introduce
a more comprehensive API for this. There is other platform-specific
PMU support in the kernel, so I'd lean towards leaving that task for
later, also since a proper design may take a while. The
PCF50633-specific items are tied up in platform-specific code, so
the lack of a more general API doesn't cause contamination of
platform-independent drivers. (Notable exception: glamo-mci.c, but I
think that is an oversight.)

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.

- Werner