Hi Olof,
Thanks for the comments. Please see my questions inline before we
determine what needs to be done for the defconfig patchset.
On 14-11-08 04:13 PM, Olof Johansson wrote:
On Thu, Oct 30, 2014 at 12:50:09PM -0700, Florian Fainelli wrote:
The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
are available in the git repository at:
http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-defconfig-v9
for you to fetch changes up to aa0204801143ee2d47e9e8dd5f39cdddd5613b4b:
ARM: multi_v7_defconfig: Enable Broadcom Cygnus (2014-10-30 11:01:35 -0700)
Hi Florian,
Apologies for the delay in dealing with this pull request.
----------------------------------------------------------------
This patchset contains initial support for Broadcom's Cygnus SoC based on our
iProc architecture. Initial support is minimal and includes just the mach
platform code, clock driver, and a basic device tree configuration. Peripheral
drivers will be submitted soon, as will device tree configurations for other
Cygnus board variants.
These are the defconfig parts of the changes
----------------------------------------------------------------
Jonathan Richardson (1):
ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
Ray Jui (1):
ARM: multi_v7_defconfig: Enable Broadcom Cygnus
Scott Branden (1):
ARM: bcm_defconfig/multi_v7_defconfig: remove one level of menu from Kconfig
arch/arm/configs/bcm_cygnus_defconfig | 237 ++++++++++++++++++++++++++++++++++
arch/arm/configs/bcm_defconfig | 3 +-
arch/arm/configs/multi_v7_defconfig | 21 ++-
Please send multi_v7_defconfig updates as a patch instead of including in
a merge request. We ask for this because it's a file that many maintainers
touch and it's easy that we get lots of conflicts otherwise.
OK, easy to do. Are there other files that we need to be aware of that
have these different requirements to merge as well?
As far as the bcm_cygnus_defconfig: Since new platforms are multiplatform
enabled by default, we normally only prefer to have one defconfig per vendor.
We've made exceptions in cases where the families are very different, but in
general one defconfig per vendor should be sufficient.
I.e. please enable the cygnus options in bcm_defconfig instead of adding a new
one.
Hi Olof, we can do this. But this makes bcm_defconfig unusable for us
in a product and is not a simple configuration to start from for our
customers. bcm_defconfig is a different SoC family based around the
Kona architecture. bcm_defconfig won't be what we build and test on
Cygnus at all. There is a script in scripts/kconfig/mergeconfig.pl that
allows you to merge config files together if you wish to have a kernel
support multiple SoCs. I see the same problem with multi_v7_defconfig
but even worse. It isn't a configuration we will ever use. Its only
purpose seems to be to enable our drivers in the that build just in case
somebody else happens to break something in the build.
As it stands, multi_v7_defconfig boots noticably slower than
bcm_cygnus_defconfig. And, the kernel is larger than we want. And, the
kconfigs are more complicated than we need for our boards. I also
notice some of the other SoCs families enabled automatically turn on a
lot of features we don't want on.
Perhaps most of the multi_v7_defconfig merge issue you are facing could
be solved if you used the mergconfig.pl script to merge multiple
defconfigs together?
What we wish to do is have a config file that only supports the Cygnus
family of SoCs. This allows others to easily see what applies to Cygnus
without being confused by other configurations. And, if somebody wishes
to use scripts/kconfig/mergeconfig.pl to merge different SoC support
together they are free to do so.
So, we can do as you ask to get this upstreamed. But it really serves
little purpose for us other than verifying things build.
Where do we upstream the defconfig that we actually use? Or is this
just not done and everyone keeps everything locally and has to continue
to maintain it there?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
