Policy question: criteria for submission to mainline for a new SoC?

Policy question: criteria for submission to mainline for a new SoC?

[Jason McMullan]

Hi there! So, I have the responsibility of handling our Linux Kernel
GPL requirements at Netronome for our NFP3200 series of processors
(ARM MPCore based SoCs with 40 IXP style microengines), and I have
some policy questions.

We (currently) have two products that the NFP3200 is mounted on,
both of which are evaluation devices for our customers. We provide
our customers *complete* source code for *all* GPL components
(Linux, Busybox, root fs, etc. etc. etc).

We also provide our customers non-GPL components (custom bootloader,
board initialization routines, etc), if they wish to go the uCOS
or VxWorks path.

So our customers (and anyone who asks us for a copy of the GPL
component sources) are covered, and, as far as I can tell, we are
GPL compliant. (If not, let me know, and we'll fix it!)

However, I am not sure if it is worth cluttering up the Linux ARM
arch mainline with yet another rare SoC. If the Linux ARM community
would like the sources, I am more than willing to post them on
the list, but there's not much new or interesting to see - just
a lot of trivial SoC hardware details.

So, the questions are:

A) Is anyone interested in the NFP3200 SoC patches?

B) What is the general policy for '# of units sold' for whether
   a SoC should be added to the Linux ARM mainline?

-- 
Jason S. McMullan
Netronome Systems, Inc.
http://www.netronome.com

Policy question: criteria for submission to mainline for a new SoC?

[Marek Vasut]

Dne Po 23. srpna 2010 17:20:43 Jason McMullan napsal(a):
> Hi there! So, I have the responsibility of handling our Linux Kernel
> GPL requirements at Netronome for our NFP3200 series of processors
> (ARM MPCore based SoCs with 40 IXP style microengines), and I have
> some policy questions.
> 
> We (currently) have two products that the NFP3200 is mounted on,
> both of which are evaluation devices for our customers. We provide
> our customers *complete* source code for *all* GPL components
> (Linux, Busybox, root fs, etc. etc. etc).
> 
> We also provide our customers non-GPL components (custom bootloader,
> board initialization routines, etc), if they wish to go the uCOS
> or VxWorks path.

Most of the board init routines should be in Linux actually. It shouldn't depend 
on bootloader. Also, you might want to use uboot for linux instead of custom 
bootloader.
> 
> So our customers (and anyone who asks us for a copy of the GPL
> component sources) are covered, and, as far as I can tell, we are
> GPL compliant. (If not, let me know, and we'll fix it!)

Why not just sticking the sources on the website somewhere ?
> 
> However, I am not sure if it is worth cluttering up the Linux ARM
> arch mainline with yet another rare SoC. If the Linux ARM community
> would like the sources, I am more than willing to post them on
> the list, but there's not much new or interesting to see - just
> a lot of trivial SoC hardware details.

Please do.
> 
> So, the questions are:
> 
> A) Is anyone interested in the NFP3200 SoC patches?

Yes.
> 
> B) What is the general policy for '# of units sold' for whether
>    a SoC should be added to the Linux ARM mainline?

No, >= 1 should do.

Cheers

Policy question: criteria for submission to mainline for a new SoC?

[Amit Kucheria]

On Mon, Aug 23, 2010 at 6:20 PM, Jason McMullan
<jason.mcmullan@netronome.com> wrote:
>
> However, I am not sure if it is worth cluttering up the Linux ARM
> arch mainline with yet another rare SoC. If the Linux ARM community
> would like the sources, I am more than willing to post them on
> the list, but there's not much new or interesting to see - just
> a lot of trivial SoC hardware details.

Don't think of it as cluttering up. The Linux kernel changes so fast
that by pushing code into mainline, you'll offload some of the more
mundane maintenance tasks over to the kernel developers. So you won't
have to track internal API changes when you rebase your internal git
tree to the latest version of the Linux kernel.

This is not to say that you can simply email those patches to LAKML
and assume your job is done. It might have to be refactored to suit
the style of code in the kernel. But in the end you'll benefit from
better quality code and probably even code reduction.

> So, the questions are:
>
> A) Is anyone interested in the NFP3200 SoC patches?

Yes, it also makes the Linux kernel better by allowing subsystems to
be designed/refactored to take into account various needs.

> B) What is the general policy for '# of units sold' for whether
> ? a SoC should be added to the Linux ARM mainline?

Even a single board shipped is enough :) See this informative talk by
Greg KH (http://www.kroah.com/log/linux/ols_2006_keynote.html)

Cheers,
Amit

Policy question: criteria for submission to mainline for a new SoC?

[Jassi Brar]

On Tue, Aug 24, 2010 at 12:20 AM, Jason McMullan
<jason.mcmullan@netronome.com> wrote:

> B) What is the general policy for '# of units sold' for whether
> ? a SoC should be added to the Linux ARM mainline?

I guess no policy as such, just a tacit understanding that there
does/will exist sufficient
'users' of the device that would be interested in keeping the support
up-to-date and
test any changes. If you push the code just for the sake of it, it'll
only add to the crowd.
Or so do I think.

Policy question: criteria for submission to mainline for a new SoC?

[Jason McMullan]

On Mon, Aug 23, 2010 at 11:26 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Most of the board init routines should be in Linux actually. It shouldn't depend
> on bootloader. Also, you might want to use uboot for linux instead of custom
> bootloader.

As much as I would like to, several of our board initialization
routines (specifically DDR3, TCAM, and RXAUI) are under NDA
by our suppliers, and can't be included in U-Boot.

> Why not just sticking the sources on the website somewhere ?

We're working on that.


-- 
Jason S. McMullan
Netronome Systems, Inc.

Policy question: criteria for submission to mainline for a new SoC?

[Mark Brown]

On Mon, Aug 23, 2010 at 12:39:03PM -0400, Jason McMullan wrote:
> On Mon, Aug 23, 2010 at 11:26 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Most of the board init routines should be in Linux actually. It shouldn't depend
> > on bootloader. Also, you might want to use uboot for linux instead of custom
> > bootloader.

> As much as I would like to, several of our board initialization
> routines (specifically DDR3, TCAM, and RXAUI) are under NDA
> by our suppliers, and can't be included in U-Boot.

If you're doing this please make sure you provide a method for customers
to customise the machine type (and get the rest of the boot protocol
right).

Policy question: criteria for submission to mainline for a new SoC?

[Marek Vasut]

Dne Po 23. srpna 2010 18:53:17 Mark Brown napsal(a):
> On Mon, Aug 23, 2010 at 12:39:03PM -0400, Jason McMullan wrote:
> > On Mon, Aug 23, 2010 at 11:26 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > > Most of the board init routines should be in Linux actually. It
> > > shouldn't depend on bootloader. Also, you might want to use uboot for
> > > linux instead of custom bootloader.
> > 
> > As much as I would like to, several of our board initialization
> > routines (specifically DDR3, TCAM, and RXAUI) are under NDA
> > by our suppliers, and can't be included in U-Boot.
> 
> If you're doing this please make sure you provide a method for customers
> to customise the machine type (and get the rest of the boot protocol
> right).

You can still release the code, can't you ? Or the NDA is so restrictive it 
covers even the code?

Cheers

Policy question: criteria for submission to mainline for a new SoC?

[Jason McMullan]

On Mon, Aug 23, 2010 at 12:53 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> If you're doing this please make sure you provide a method for customers
> to customise the machine type (and get the rest of the boot protocol
> right).

Machine type (atag id) is one of the many customizable parameters.
I was itching to use Flattened Device Tree to hold these parameters,
but as far as I can tell that 'isn't ready for prime time' on ARM at
the moment.

--
Jason S. McMullan
Netronome Systems, Inc.

Policy question: criteria for submission to mainline for a new SoC?

[Jason McMullan]

On Mon, Aug 23, 2010 at 1:12 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>
> You can still release the code, can't you ? Or the NDA is so restrictive it
> covers even the code?
>

I am not in a position to be able to definitively say (as I am
not involved in the negotiation of those agreements). For now,
I have to take a very conservative approach to those NDAs.

-- 
Jason S. McMullan
Netronome Systems, Inc.