Hi,
Our team in Broadcom plan to submit our code of a new ARM11 SoC support to kernel.org.
As we have no experience in doing this, I hope that we can get some more information regarding the code submission.
1. We have a whole lot of OS-less csp (chip support package) code that is used in our drivers and arch code. We will release them as GPL but we want to keep and maintain them in our own csp directories. Can we put them under arch/arm/mach-bcmring/csp and arch/arm/mach-bcmring/include/csp directories? If not, what's the proper way to do that?
2. We have driver header files which are currently kept in the include/linux/broadcom directory. Where is the proper place to put our driver header files in Linux kernel? Any guidelines?
3. Do I need to submit our code to any maintainer or just submit to LKML?
Thanks a lot,
-------------
Leo Hao Chen
Software Engineer
Broadcom Canada Inc.
604-233-8694
> 1. We have a whole lot of OS-less csp (chip support package) code that is used in our drivers and arch code. We will release them as GPL but we want to keep and maintain them in our own csp directories. Can we put them under arch/arm/mach-bcmring/csp and arch/arm/mach-bcmring/include/csp directories? If not, what's the proper way to do that?
Difficult to tell without seeing it.
> 2. We have driver header files which are currently kept in the include/linux/broadcom directory. Where is the proper place to put our driver header files in Linux kernel? Any guidelines?
Headers generally go in locations according to what they are for.
Thus
arch/arm/plat-[name]/include/plat
arch/arm/mach-[name]/include/mach
Stuff that defines public (user space) interfaces and structures tends to
be in include/linux while there are directories such as include/net/
include/usb/ - split by function rather than platform
> 3. Do I need to submit our code to any maintainer or just submit to LKML
Core changes that affect the internals of things like arch/arm and
include/asm-arm need to go via the maintainer (see MAINTAINERS): In this
case Russell King - and see: http://www.arm.linux.org.uk
After that platform changes can begin to go in, and then drivers. If you
are new to this then initially going through another maintainer will help
with quality and correctness, but after a time a lot of stuff would go
directly (stuff that affected only bcmring drivers/code). That also is a
good reason to keep as much of the code separated cleanly from the core
code as possible.
Hi Leo,
On Wed, Jun 17, 2009 at 1:14 AM, Leo (Hao) Chen <[email protected]> wrote:
> Hi,
>
> Our team in Broadcom plan to submit our code of a new ARM11 SoC support to kernel.org.
> As we have no experience in doing this, I hope that we can get some more information regarding the code submission.
>
> 1. We have a whole lot of OS-less csp (chip support package) code that is used in our drivers and arch code. We will release them as GPL but we want to keep and maintain them in our own csp directories. ?Can we put them under arch/arm/mach-bcmring/csp and arch/arm/mach-bcmring/include/csp directories? ?If not, what's the proper way to do that?
As Alan mentioned, it is difficult to comment without seeing it.
Please also subscribe :) to arm-linux-kernel mailing list so you could
have interaction with arm-linux-kernel community. But you can always
CC linux-kernel :).
>
> 2. We have driver header files which are currently kept in the include/linux/broadcom directory. ?Where is the proper place to put our driver header files in Linux kernel? ?Any guidelines?
>
> 3. Do I need to submit our code to any maintainer or just submit to LKML?
ARM-Linux kernel maintainer is Russell King. Please post your patches
to linux-arm-kernel mailing list and CC LKML. You should first target
mainlining your "mach-bcmring" core code, which should atleast be able
to get your serial console and minimal filesystem. Other additional
drivers can be submitted once core code gets in.
--
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni