| Message ID | 4b150d01c60bd37705789200d9adee9f1c9b50ce.1584699455.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Disable compat cruft on ppc64le v12 | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/merge (8a445cbcb9f5090cb07ec6cbb89a8a1fc99a0ff7) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/next (59ed2adf393109c56d383e568f2e57bb5ad6d901) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linus/master (6c90b86a745a446717fdf408c4a8a4631a5e8ee3) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/fixes (af3d0a68698c7e5df8b72267086b23422a3954bb) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linux-next (d8f289c16fbb72e17b783175c1fb0942816264fd) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > While at it also simplify the existing perf patterns. > And still missed fixes from parse-maintainers.pl. I see it like below in the linux-next (after the script) PERFORMANCE EVENTS SUBSYSTEM M: Peter Zijlstra <peterz@infradead.org> M: Ingo Molnar <mingo@redhat.com> M: Arnaldo Carvalho de Melo <acme@kernel.org> R: Mark Rutland <mark.rutland@arm.com> R: Alexander Shishkin <alexander.shishkin@linux.intel.com> R: Jiri Olsa <jolsa@redhat.com> R: Namhyung Kim <namhyung@kernel.org> L: linux-kernel@vger.kernel.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core F: arch/*/events/* F: arch/*/events/*/* F: arch/*/include/asm/perf_event.h F: arch/*/kernel/*/*/perf_event*.c F: arch/*/kernel/*/perf_event*.c F: arch/*/kernel/perf_callchain.c F: arch/*/kernel/perf_event*.c F: include/linux/perf_event.h F: include/uapi/linux/perf_event.h F: kernel/events/* F: tools/perf/ > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13080,7 +13080,7 @@ R: Namhyung Kim <namhyung@kernel.org> > L: linux-kernel@vger.kernel.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > S: Supported > -F: kernel/events/* > +F: kernel/events/ > F: include/linux/perf_event.h > F: include/uapi/linux/perf_event.h > F: arch/*/kernel/perf_event*.c > @@ -13088,8 +13088,8 @@ F: arch/*/kernel/*/perf_event*.c > F: arch/*/kernel/*/*/perf_event*.c > F: arch/*/include/asm/perf_event.h > F: arch/*/kernel/perf_callchain.c > -F: arch/*/events/* > -F: arch/*/events/*/* > +F: arch/*/events/ > +F: arch/*/perf/ > F: tools/perf/ > > PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS
On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > While at it also simplify the existing perf patterns. > > > > And still missed fixes from parse-maintainers.pl. Oh, that script UX is truly ingenious. It provides no output and quietly creates MAINTAINERS.new which is, of course, not included in the patch. Thanks Michal > > I see it like below in the linux-next (after the script) > > PERFORMANCE EVENTS SUBSYSTEM > M: Peter Zijlstra <peterz@infradead.org> > M: Ingo Molnar <mingo@redhat.com> > M: Arnaldo Carvalho de Melo <acme@kernel.org> > R: Mark Rutland <mark.rutland@arm.com> > R: Alexander Shishkin <alexander.shishkin@linux.intel.com> > R: Jiri Olsa <jolsa@redhat.com> > R: Namhyung Kim <namhyung@kernel.org> > L: linux-kernel@vger.kernel.org > S: Supported > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > F: arch/*/events/* > F: arch/*/events/*/* > F: arch/*/include/asm/perf_event.h > F: arch/*/kernel/*/*/perf_event*.c > F: arch/*/kernel/*/perf_event*.c > F: arch/*/kernel/perf_callchain.c > F: arch/*/kernel/perf_event*.c > F: include/linux/perf_event.h > F: include/uapi/linux/perf_event.h > F: kernel/events/* > F: tools/perf/ > > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -13080,7 +13080,7 @@ R: Namhyung Kim <namhyung@kernel.org> > > L: linux-kernel@vger.kernel.org > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > > S: Supported > > -F: kernel/events/* > > +F: kernel/events/ > > F: include/linux/perf_event.h > > F: include/uapi/linux/perf_event.h > > F: arch/*/kernel/perf_event*.c > > @@ -13088,8 +13088,8 @@ F: arch/*/kernel/*/perf_event*.c > > F: arch/*/kernel/*/*/perf_event*.c > > F: arch/*/include/asm/perf_event.h > > F: arch/*/kernel/perf_callchain.c > > -F: arch/*/events/* > > -F: arch/*/events/*/* > > +F: arch/*/events/ > > +F: arch/*/perf/ > > F: tools/perf/ > > > > PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS > > -- > With Best Regards, > Andy Shevchenko > >
On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > While at it also simplify the existing perf patterns. > > And still missed fixes from parse-maintainers.pl. > > Oh, that script UX is truly ingenious. You have at least two options, their combinations, etc: - complain to the author :-) - send a patch :-) > It provides no output and quietly > creates MAINTAINERS.new which is, of course, not included in the patch. Yes. it also took me a while to understand how it works, luckily it has a little help note.
On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > While at it also simplify the existing perf patterns. > > > And still missed fixes from parse-maintainers.pl. > > > > Oh, that script UX is truly ingenious. > > You have at least two options, their combinations, etc: > - complain to the author :-) > - send a patch :-) Recently: https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote: > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > > While at it also simplify the existing perf patterns. > > > > And still missed fixes from parse-maintainers.pl. > > > > > > Oh, that script UX is truly ingenious. > > > > You have at least two options, their combinations, etc: > > - complain to the author :-) > > - send a patch :-) > > Recently: > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/ Can we expect that reaordering is taken care of in that discussion then? Thanks Michal
On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote: > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > > While at it also simplify the existing perf patterns. > > > > And still missed fixes from parse-maintainers.pl. > > > > > > Oh, that script UX is truly ingenious. > > > > You have at least two options, their combinations, etc: > > - complain to the author :-) > > - send a patch :-) > > Recently: > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/ But why? Shouldn't we rather run MAINTAINERS clean up once and require people to use parse-maintainers.pl for good?
On Fri, Mar 20, 2020 at 06:31:57PM +0200, Andy Shevchenko wrote: > On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote: > > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > > > While at it also simplify the existing perf patterns. > > > > > And still missed fixes from parse-maintainers.pl. > > > > > > > > Oh, that script UX is truly ingenious. > > > > > > You have at least two options, their combinations, etc: > > > - complain to the author :-) > > > - send a patch :-) > > > > Recently: > > > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/ > > But why? > > Shouldn't we rather run MAINTAINERS clean up once and require people to use > parse-maintainers.pl for good? That cleanup did not happen yet, and I am not volunteering for one. The difference between MAINTAINERS and MAINTAINERS.new is: MAINTAINERS | 5510 +++++++++++++++++++++++++++++------------------------------ 1 file changed, 2755 insertions(+), 2755 deletions(-) Thanks Michal
On Fri, Mar 20, 2020 at 05:42:04PM +0100, Michal Suchánek wrote: > On Fri, Mar 20, 2020 at 06:31:57PM +0200, Andy Shevchenko wrote: > > On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote: > > > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > > > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > > > > While at it also simplify the existing perf patterns. > > > > > > And still missed fixes from parse-maintainers.pl. > > > > > > > > > > Oh, that script UX is truly ingenious. > > > > > > > > You have at least two options, their combinations, etc: > > > > - complain to the author :-) > > > > - send a patch :-) > > > > > > Recently: > > > > > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/ > > > > But why? > > > > Shouldn't we rather run MAINTAINERS clean up once and require people to use > > parse-maintainers.pl for good? > > That cleanup did not happen yet, and I am not volunteering for one. > The difference between MAINTAINERS and MAINTAINERS.new is: > > MAINTAINERS | 5510 +++++++++++++++++++++++++++++------------------------------ > 1 file changed, 2755 insertions(+), 2755 deletions(-) Yes, it was basically reply to Joe.
(removed a bunch of cc's) On Fri, 2020-03-20 at 18:31 +0200, Andy Shevchenko wrote: > On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote: > > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote: > > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote: > > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote: > > > > > > While at it also simplify the existing perf patterns. > > > > > And still missed fixes from parse-maintainers.pl. > > > > > > > > Oh, that script UX is truly ingenious. > > > > > > You have at least two options, their combinations, etc: > > > - complain to the author :-) > > > - send a patch :-) > > > > Recently: > > > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/ > > But why? > > Shouldn't we rather run MAINTAINERS clean up once and require people to use > parse-maintainers.pl for good? That can basically only be done by Linus just before he releases an RC1. I am for it. One day...
diff --git a/MAINTAINERS b/MAINTAINERS index e1a99197fb34..578429d22220 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13080,7 +13080,7 @@ R: Namhyung Kim <namhyung@kernel.org> L: linux-kernel@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core S: Supported -F: kernel/events/* +F: kernel/events/ F: include/linux/perf_event.h F: include/uapi/linux/perf_event.h F: arch/*/kernel/perf_event*.c @@ -13088,8 +13088,8 @@ F: arch/*/kernel/*/perf_event*.c F: arch/*/kernel/*/*/perf_event*.c F: arch/*/include/asm/perf_event.h F: arch/*/kernel/perf_callchain.c -F: arch/*/events/* -F: arch/*/events/*/* +F: arch/*/events/ +F: arch/*/perf/ F: tools/perf/ PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS
While at it also simplify the existing perf patterns. Signed-off-by: Michal Suchanek <msuchanek@suse.de> --- v10: new patch V12: remove redundant entries --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)