Patch upstream sending

If you like to share the effort you put into creating a patch, it is highly appreciated if you send it upstream. For DaVinci kernel specific patches Open Source DaVinci Mailing List (ML) is the correct target.

General patch flow

The patch flow for DaVinci is similar to OMAP one. The way is to send core architecture patches to DaVinci ML and subsystem patches (e.g. sound, ide etc.) to subsystem lists and Cc DaVinci ML. Talking about core DaVinci patches, they are reviewed on the list and then applied to DaVinci git repository.

Then from time to time, if patches are ready for mainline, git maintainer sends a patch series to linux-arm-kernel (LAK) ML for review and at the same time prepares a git branch (e.g. "mainline merge") with only these patches in it. With this, the patches on the LAK ML and in Russell (Michael) King's (RMK, Linux ARM maintainer) patch system are only there for review. If they are okay, RMK directly pulls them from git.

A short note from Kevin regarding this:

I prefer that DaVinci patches first go to the davinci list and get applied to DaVinici git. I will then organize and submit to RMK. ... I have no objections to other driver/subsystem patches going directly to the maintainers (with me and/or davinci list in Cc) ... That is my preference. However, for ARM core stuff, I prefer it goes through myself and via DaVinci git where I can organize and re-order for submission via RMK.

CCing LAK is optional for all patches. But, please, please, don't send DaVinci related patches to other lists (e.g LAK or subsystem related) without CC'ing this DaVinci list!

Patch rules

This section gives you some rules you should ensure your patch is compatible with before sending it to DaVinci ML. The reason for this is to produce a clean revision history, make maintenance easier, and give proper credit to the patch author.

Before submitting a patch to Open Source DaVinci ML, please check the following:

• Patch follows linux/Documentation/CodingStyle

• Patch follows linux/Documentation/SubmittingPatches

• Patch does not cause warnings when checked with scripts/checkpatch.pl. Using this script is quite easy: Go to kernel main directory (where you normally build you kernel with e.g. make uImage) and there call

./scripts/checkpatch.pl <path_to_your_patch>/<your_patch> 

• Patch does not use double spaces except in comments. Please use tabs or single space instead. Upstream merge tools check for these, so they will potentially cause a different patch to be applied compared to mainline.

• Make sure your patch applies without rejects to a recent DaVinci git kernel.

• If your patch is on top of other patches or needs other patches to be applied that are not yet in git, note this.

• Patch subject must be [PATCH] xxx: DaVinci: <Subject of the patch>. The subject will go into git as the name of the patch.
  • Replace xxx above with ARM if the patch is about core code (see below) resulting in [PATCH] ARM: DaVinci: <short summary>.
  • For other subsystems (e.g. drivers) replace xxx with a prefix for the subsystem. For example, if it's a patch to the MMC driver for DaVinci, it should look like: [PATCH] MMC: DaVinci: <short summary> etc.

• Patch body must contain short description of the patch. This description will go into git as the patch description.

• Patch body must contain proper Signed-off-by: line

• If your patch consists of different parts (i.e. several patch files) then number the patch files (e.g. 01_<patch_filename>, 02_<patch_filename>).

• If your patch consists of different parts (i.e. several patch files), you should send x + 1 separate mails (with x == number of patches). The first (0/x) with a general description what the patches are about. Here you can write everything you like, it doesn't go to git. This 0/x mail has no patch attached/included. Then x mails with the x patches (1/x, 2/x until x/x) with the signed of by and the exact description of this patch. This text then goes into git. For core DaVinci patches this might look e.g.

[PATCH 0/x] ARM: DaVinci: <brief one-liner summary of this patch series>

This patch series <any useful description not going to git>

[PATCH 1/x] ARM: DaVinci: <brief one-liner summary of this patch>

<description of this patch going into git>

Signed-off-by: ...

<Patch inlined, if attachment with filename starting 01_...>

[PATCH 2/x] ARM: DaVinci: <brief one-liner summary of this patch>

<description of this patch going into git>

Signed-off-by: ...

<Patch inlined, if attachment with filename starting 02_...>

[PATCH x/x] ARM: DaVinci: ...

...

• Patches should be in patch -p1 form (i.e. with strip level 1):

 --- a/kernel/sched.c
 +++ b/kernel/sched.c

• Open Source DaVinci ML has a size limit of (tbd.) kByte for a single mail/attachment. If your patch is larger, split it into several reasonable parts.

Note: E.g. U-Boot ML has size limit of 40 kByte.

• Open Source DaVinci ML accepts patches as mail attachments. However, inline patches are preferred. If you use attachments, make sure that attachments are marked by your mailer as mime/text, though. There seems to be some agreement that git-send-email is the preferred tool to send patches to inline-only MLs.

Note: On some lists, there are other requirements how patches have to be send. E.g. Linux Kernel Mailing List (LKML) and U-Boot mailing list only accept inline patches. This often leads to some trouble on patch sender side how to do this correctly. For this, email clients readme in Linux kernel Documentation can help you.

Note: Don't use Outlook to send patches to mailing lists. Don't do it. But you have to do? E.g. because of company rules? Then, and only then, have a look to Nishant Menon's Outlook hints.

• DaVinci related patches go to:
  • Non-core patches (e.g. drivers) should go to subsystem MLs/maintainers and Cc to DaVinci ML. They should have the subject [PATCH] <subsystem>: DaVinci: <short summary> (see above).
  • Core patches go to DaVinci ML. They use the subject [PATCH] ARM: DaVinci: <short summary> as described above. DaVinci core patches are patches that do changes under

arch/arm/mach-davinci
include/asm-arm/arch-davinci

• If you like to resend a patch (e.g. after incorporating review results) please note that it is an update (e.g. this is version x of ...), note which patch it replaces (e.g. this replaces ...) and what the changes are (e.g. review comments ... incorporated). Depending of the patch series, it can make sense to repost the whole series. Marking then the subject with version e.g. [PATCH 0/x v2] or [PATCH 0/x take #2] can be helpful.

• If you tested or reviewed some patches, please send you findings to DaVinci ML. If a patch is okay and you like to have it applied, express this with a Acked-by:. See SubmittingPatches when and how to use Acked-by. E.g.

... Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance. Hence patch mergers will sometimes manually convert an acker's "yep, looks good to me" into an Acked-by:. ...

Pending patches and broken stuff

You want to send a patch, or you want to help fix broken/open things? But you don't know which patches are already there or which things are still open? See DaVinci patches. loan modification

Further reading

• Working with Linux patches
• OMAP patches readme
• DaVinci patch submission hints on DaVinci ML
• The perfect patch.

Outlook config

Nishant Menon gave this Outlook configuration hints: