* Andi Kleen <a...@firstfloor.org> wrote: > v12: Rebase to 3.10-rc2 > Add mem-loads/stores support for parity with Sandy Bridge. > Fix fixed counters (Thanks Ingo!) > Make late ack optional > Export new config bits in sysfs. > Minor changes
Sigh, what you have not fixed in your patches are the basic stylistic mistakes I pointed out to the past: https://lkml.org/lkml/2013/5/1/78 (my previous feedback is also quoted below.) Here checkpatch.pl says this about your series: total: 6 errors, 10 warnings, 662 lines checked and a handful of those checkpatch.pl complaints are for valid, real problems. Furthermore, you have not replied to any of those two mails of mine, nor have you fixed the stylistic problems I pointed out, in these latest patches! To fix it simply follow the advice I gave you twice before: run scripts/checkpatch.pl against your patches and address any valid complaints it gives _BEFORE YOU RESUBMIT THEM_! Andi, what the heck is going on here? Your behavior makes no sense to me. You are pretty much the only contributor I know who makes a habit out of willfully ignoring maintainer feedback... Thanks, Ingo ---------------------> * Ingo Molnar <mi...@kernel.org> wrote: > > * Ingo Molnar <mi...@kernel.org> wrote: > > > > > * Ingo Molnar <mi...@kernel.org> wrote: > > > > > You say it's barebones, yet it does not work :-( How well was this > > > patch-set tested on non-Haswell hardware, which makes up 99.99% of our > > > installed base? > > > > > > In particular, after applying your patches, 'perf top' stopped working > > > on an Intel testbox of mine: > > > > The other problem I noticed was stylistic: when I applied your patches for > > testing even Git complained about their cleanliness ... > > > > To quote from Documentation/SubmittingPatches: > > > > 4) Style check your changes. > > > > Check your patch for basic style violations, details of which can be > > found in Documentation/CodingStyle. Failure to do so simply wastes > > the reviewers time and will get your patch rejected, probably > > without even being read. > > > > At a minimum you should check your patches with the patch style > > checker prior to submission (scripts/checkpatch.pl). You should > > be able to justify all violations that remain in your patch. > > > > Please make your patches less sloppy! > > Andi, you have not replied to this mail of mine. > > What new measures are you taking to avoid such annoying stylistic problems > to creep into your patches? > > These problems are regular in your patches and that has been going on for > years - causing maintenance overhead for many maintainers, not just me. > > Apparently you are not using proper tooling (checkpatch.pl for example) to > check your patches. If you refuse to take action I will have to stop > dealing with your patches directly altogether - the overhead just does not > justify the effort. You'll need to get your patches reviewed by and signed > off by a more experienced kernel hacker who knows how to submit patches. > > Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
