Re: [PATCH] MFD of DA9052 Linux device drivers (1/9)

[Jonathan Cameron <kernel@jic23.retrosnub.co.uk>]

On 05/19/10 10:16, David Dajun Chen wrote:
> Dear sir/madam,
> 
> The attached is the MFD part of the device drivers newly developed for DA9052 Power Management IC from Dialog Semiconductor.
> 
> Regards

Dear David,

Whilst it is good to see you have broken the da9052 support up into a number
of different patches there are still a number of issues with how this patch
set is presented that will make it difficult for anyone to review and even
harder for anyone to test (even if it is just build testing).

Firstly, the naming of the patches.  Convention says that a series of 9 like
this should probably have an explanatory cover letter. If you are using
git (if you are not, please move to it as it makes putting together large
sets like this in the right format trivial). Typically that email subject
would be

[PATCH 0/9] DA9052 driver

Then the others would be
[PATCH 1/9] DA9052 mfd
[PATCH 2/9] ....
Ideally all these patches in the series should be replies to the first email.
(If you can use git send-email it will do this nicely for you).

The next thing is that the structure at the top of the patch is very formal
and here git format-patch will do the hard work for you.

A typical git format-patch call for this series (assuming they are the last nine
patches in your tree) would look like

git format-patch --patch-with-stat --cover-letter -o for-lkml HEAD^^^^^^^^^
Then you edit the resulting files in the for-lkml directory.

Please be careful not to change the overall layout. Any comments should go
below the --- line just above the stats. Also please try to work out how
to get rid of the block disclaimer at the bottom of this email or prefix
with a line containing -- as iirc that will make git am (which applies the
patches to someone elses tree) ignore the signature.

Please review the documentation on submitting patches (in the Documentation
directory of the kernel tree) for more guidance on getting this right.

It may seem over restrictive but it saves reviewers a lot of time an hassel
and generally makes them more likely to take a look at your patches.

Jonathan

(p.s. if you are still unsure on patch formatting, feel free to send me any
patches first and I'll take a quick look for any of the things likely to annoy
other reviewers!)