linux-kernel - Re: New MIPS SoC code insertion request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160414173649.GB1003@linux-mips.org>
Date:	Thu, 14 Apr 2016 19:36:49 +0200
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Dmitry.Dunaev@...kalelectronics.ru
Cc:	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org,
	Constantine.Gurin@...kalelectronics.ru,
	Alexey.Malahov@...kalelectronics.ru
Subject: Re: New MIPS SoC code insertion request

On Thu, Apr 14, 2016 at 02:43:06PM +0000, Dmitry.Dunaev@...kalelectronics.ru wrote:

> I'm Dmitry Dunaev, software designer from Baikal Electronics - Russian
> semiconductor company (http://www.baikalelectronics.com/). Some time ago
> we are released our first MIPS processor based on P5600 core
> (https://www.linux-mips.org/wiki/Baikal).
> 
> Now we have this SoC in silicon. Also we have released several revisions
> of development boards for our SoC. So it seems that we ready to add our
> platform code into Linux kernel mainline.
> 
> Could you please clarify me what steps we should to do to add our code
> into kernel repositary?

I generally recommend to start the process of upstreaming the code early
possibly even before general availability of a new SoC or platform.
Generally the process of posting a version of patches, review, changing
issues has to go through several cycles before the code and documentation
will have reached a shape where it is deemed acceptable.  And even then
code will only be accepted for the merge window of the next kernel
release so worst case that could be another like good four months.

Basically the steps are:

 - Cleanup your code.
 - Split your patches into reasonably sized patches.  You are using
   git to create postable patches, so use options -C -M to enable the
   copy and rename detection which may make patches much smaller and
   easier to review.
 - Read the following files in the kernel:

     Documentation/SubmitChecklist
     Documentation/SubmittingDrivers
     Documentation/SubmittingPatches

Here's an example how a reasonably split patchset to add a new feature
may look like:

  https://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1459415142-3412-1-git-send-email-matt.redfearn%40imgtec.com

And another one adding support for a new platform including a few drivers:

  https://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1452734299-460-1-git-send-email-joshua.henderson%40microchip.com

I assume you will be posting several support for the core platfroms as well
as several drivers.  If the maintainers of the respective driver subsystems
are ok with that, I can carry the patches along with the platform support
in the MIPS tree which generally makes the the process somewhat easier.

  Ralf