Add a Linux style MAINTAINERS file and the
script from the Linux kernel source (adapted to work in the
coreboot source tree)

Change-Id: I983e30c20c371d238cfa7c0a074587b731387c63
Signed-off-by: Stefan Reinauer <>
Reviewed-by: Patrick Georgi <>
Tested-by: build bot (Jenkins)
new file mode 100644
index 0000000..76e4c4c
--- /dev/null
@@ -0,0 +1,143 @@
+	List of maintainers and how to submit coreboot changes
+Please try to follow the guidelines below.  This will make things
+easier on the maintainers.  Not all of these guidelines matter for every
+trivial patch so apply some common sense.
+1.	Always _test_ your changes, however small, on at least 1 or
+	2 people, preferably many more.
+2.	Try to release a few ALPHA test versions to gerrit. Announce
+	them onto the coreboot mailing list and IRC channel and await
+	results. This is especially important on coreboot core changes,
+	but also for device drivers, because often that's the only way
+	you will find things like the fact revision 3 chipset needs
+	a magic fix you didn't know about, or some clown changed the
+	chips on a board and not its name.  (Don't laugh!)
+3.	Make sure your changes compile correctly in multiple
+	configurations. In particular check that changes work for all
+	boards in the tree (use abuild!)
+4.	When you are happy with a change make it generally available for
+	testing in gerrit and await feedback.
+5.	Make your patch available through coreboot's gerrit code review
+	system, and add the relevant maintainer from this list as a code
+	reviewer. Be prepared to get your changes sent back with seemingly
+	silly requests about formatting and variable names.  These aren't
+	as silly as they seem. One job the maintainers do is to keep
+	things looking the same.  Sometimes this means that the clever
+	hack in your mainboard or chipset to get around a problem actually
+	needs to become a generalized coreboot feature ready for next time.
+	PLEASE check your patch with the automated style checker
+	(util/lint/ to catch trival style violations.
+	See for guidance here.
+	PLEASE add the maintainers that are generated by
+	util/scripts/ as reviewers.  The results returned
+	by the script will be best if you have git installed and are
+	making your changes in a branch derived from's latest
+	git tree.
+	PLEASE try to include any credit lines you want added with the
+	patch. It avoids people being missed off by mistake and makes
+	it easier to know who wants adding and who doesn't.
+	PLEASE document known bugs. If it doesn't work for everything
+	or does something very odd once a month document it.
+	PLEASE remember that submissions must be made under the terms
+	of the OSDL certificate of contribution and should include a
+	Signed-off-by: line.  The current version of this "Developer's
+	Certificate of Origin" (DCO) is listed at
+6.	Make sure you have the right to send any changes you make. If you
+	do changes at work you may find your employer owns the patch
+	not you.
+7.	Happy hacking.
+Descriptions of section entries:
+	M: Mail patches to: FullName <address@domain>
+	R: Designated reviewer: FullName <address@domain>
+	   These reviewers should be CCed on patches.
+	L: Mailing list that is relevant to this area
+	W: Web-page with status/info
+	Q: Patchwork web based patch tracking system site
+	T: SCM tree type and location.
+	   Type is one of: git, hg, quilt, stgit, topgit
+	S: Status, one of the following:
+	   Supported:	Someone is actually paid to look after this.
+	   Maintained:	Someone actually looks after it.
+	   Odd Fixes:	It has a maintainer but they don't have time to do
+			much other than throw the odd patch in. See below..
+	   Orphan:	No current maintainer [but maybe you could take the
+			role as you write your new code].
+	   Obsolete:	Old code. Something tagged obsolete generally means
+			it has been replaced by a better system and you
+			should be using that.
+	F: Files and directories with wildcard patterns.
+	   A trailing slash includes all files and subdirectory files.
+	   F:	drivers/net/	all files in and below drivers/net
+	   F:	drivers/net/*	all files in drivers/net, but not below
+	   F:	*/net/*		all files in "any top level directory"/net
+	   One pattern per line.  Multiple F: lines acceptable.
+	N: Files and directories with regex patterns.
+	   N:	[^a-z]tegra	all files whose path contains the word tegra
+	   One pattern per line.  Multiple N: lines acceptable.
+	   scripts/ has different behavior for files that
+	   match F: pattern and matches of N: patterns.  By default,
+	   get_maintainer will not look at git log history when an F: pattern
+	   match occurs.  When an N: match occurs, git log history is used
+	   to also notify the people that have git commit signatures.
+	X: Files and directories that are NOT maintained, same rules as F:
+	   Files exclusions are tested before file matches.
+	   Can be useful for excluding a specific subdirectory, for instance:
+	   F:	net/
+	   X:	net/ipv6/
+	   matches all files in and below net excluding net/ipv6/
+	K: Keyword perl extended regex pattern to match content in a
+	   patch or file.  For instance:
+	   K: of_get_profile
+	      matches patches or files that contain "of_get_profile"
+	   K: \b(printk|pr_(info|err))\b
+	      matches patches or files that contain one or more of the words
+	      printk, pr_info or pr_err
+	   One regex pattern per line.  Multiple K: lines acceptable.
+Note: For the hard of thinking, this list is meant to remain in alphabetical
+order. If you could add yourselves to it in alphabetical order that would be
+so much easier [Ed]
+Maintainers List (try to look for most precise areas first)
+		-----------------------------------
+M:	Ronald Minnich <>
+S:	Maintained
+F:	src/arch/riscv
+F:	src/mainboard/emulation/qemu-riscv
+M:	Stefan Reinauer <>
+S:	Supported
+F:	src/mainboard/google/panther
+ATI MACH64 Driver
+S:	Orphan
+F:	drivers/ati/mach64
+M:	Stefan Reinauer <>
+T:	git
+S:	Buried alive in mainboards
+F:	*
+F:	*/