Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1378959 > unrolled thread

New MIPS SoC code insertion request

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  New MIPS SoC code insertion request <Dmitry.Dunaev@baikalelectronics.ru> - 2016-04-14 16:50 +0200
    Re: New MIPS SoC code insertion request Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> - 2016-04-14 17:30 +0200
    Re: New MIPS SoC code insertion request Ralf Baechle <ralf@linux-mips.org> - 2016-04-14 19:40 +0200

#1378959 — New MIPS SoC code insertion request

Good day!

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?

Best regards,
Dmitry Dunaev
http://www.baikalelectronics.com/

[toc] | [next] | [standalone]

#1379025

Hi Dmitry,

Thank-you very much for reaching out to the mailing list.

The Linux kernel follows a structure for patch submissions.

There’s a tutorial on github with a pdf and readmes.

https://github.com/gregkh/kernel-tutorial

Tutorial Videos on YouTube by GregKH are also very useful.

https://www.youtube.com/watch?v=LLBrBBImJt4

https://www.youtube.com/watch?v=XXix80GCvpo

These will give an overview of the entire process.

It would be nice if you could push your current working kernel
somewhere on a git server where we could see the patches
and then provide guidance accordingly.

If you don't have a public-facing git server. You could just
push the code to a repository on github and share the link.

Regards,
ZubairLK

On 14/04/16 15:43, Dmitry.Dunaev@baikalelectronics.ru wrote:
> Good day!
>
> 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?
>
> Best regards,
> Dmitry Dunaev
> http://www.baikalelectronics.com/
>

[toc] | [prev] | [next] | [standalone]

#1379150

On Thu, Apr 14, 2016 at 02:43:06PM +0000, Dmitry.Dunaev@baikalelectronics.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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web