Hi, James, I really don't want send many patches in a seris. But in practise, my single patch in linux-mips usually be ignored (even they are very simple and well described).... For example: https://patchwork.linux-mips.org/patch/17723/ https://patchwork.linux-mips.org/patch/18587/ https://patchwork.linux-mips.org/patch/18682/ Anyway, thank you for your susggestions, I will rework other patches. Huacai On Thu, Feb 15, 2018 at 7:05 PM, James Hogan <jhogan@xxxxxxxxxx> wrote: > On Sat, Jan 27, 2018 at 11:12:20AM +0800, Huacai Chen wrote: >> This patchset is prepared for the next 4.16 release for Linux/MIPS. It >> add Loongson-3A R3.1 support, enable Loongson-3's SFB at runtime, adds >> "model name" and "CPU MHz" knobs in /proc/cpuinfo which is needed by >> some userspace tools, adds Loongson-3 kexec/kdump and CPUFreq support, >> fixes CPU UART irq delivery problem, and introduces WAR_LLSC_MB to >> improve stability. >> >> V1 -> V2: >> 1, Add Loongson-3A R3.1 basic support. >> 2, Fix CPU UART irq delivery problem. >> 3, Improve code and descriptions (Thank James Hogan). >> 4, Sync the code to upstream. > > I few general suggestions that I hope will help you to get your patches > applied quicker: > > - Please have a separate series for each group of related changes in > future. It makes them more manageable, makes dependencies clearer, and > avoids unchanged resends of unrelated patches when you respin the > whole series. Series are mainly to group tightly related patches, or > because of dependencies of later patches on earlier ones (and even if > you have a series of 30 dependent patches, you can still sometimes > split it into groups and mention in the cover letters which other > pending series each series depends on). > > - More importantly, avoid moving patches between series or adding > unrelated patches to a series if possible (so probably best not to > split this series now). It makes it harder to see what has changed, > whether past feedback has been addressed, and whether new/removed > patches are new/abandoned or simply moved from/to a different series. > > - Please don't resend a series without changes, ping it if you are > concerned. It clutters patchwork for no good reason and makes it > harder to see if past feedback has been addressed. > > - Please run checkpatch on all patches before submission, and fix any > reasonable warnings and errors (i.e. there are various lines exceeding > 80 characters in this series which should be split, but some are > acceptable where its to keep a string together). > > - Please include Fixes tags where appropriate, especially where you've > Cc'd stable. > > - If you Cc stable, please state how far back it should be backported > wherever possible, > E.g. Cc: <stable@xxxxxxxxxxxxxxx> # 4.14+ > This may help finding what version a commit is first included in: > https://www.linux-mips.org/archives/linux-mips/2017-07/msg00149.html > > - Please run get_maintainer.pl on each patch to make sure you cc the > appropriate maintainers and lists (and Cc them on the cover letter > too). Its fine to skip LKML for lots of MIPS patches, but don't miss > out the appropriate subsystem maintainers and lists for patches > touching drivers/ or they'll never get acked and never get applied. > > - Split arch/mips/ and drivers/ patches wherever possible. > > Cheers > James
