[GIT PULL 6/7] Broadcom defconfig changes for 4.8 Part 1

[f.fainelli@gmail.com (Florian Fainelli)]

On 06/20/2016 02:43 PM, Scott Branden wrote:
> Hi Olof,
> 
> On 16-06-19 10:54 PM, Olof Johansson wrote:
>> On Thu, Jun 16, 2016 at 06:56:14PM -0700, Florian Fainelli wrote:
>>> The following changes since commit
>>> 1a695a905c18548062509178b98bc91e67510864:
>>>
>>>    Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>    http://github.com/Broadcom/stblinux.git
>>> tags/arm-soc/for-4.8/defconfig
>>>
>>> for you to fetch changes up to 41463c3e6eae3dfa4377069966ed02b4ba378e79:
>>>
>>>    ARM: Remove bcm_defconfig (2016-06-16 13:40:49 -0700)
>>>
>>> ----------------------------------------------------------------
>>> This pull request contains defconfig changes for Broadcom ARM-based
>>> SoCs:
>>>
>>> - Florian enables support for the BCM63xx DSL SoCs basic peripherals,
>>> enables
>>>    the networking subsystems for Set Top Box SoCs, enables the PWM,
>>> watchdog and
>>>    the AHCI controller and SATA PHY drivers
>>>
>>> - Florian removes the bcm_defconfig file which is no longer useful
>>> and updates
>>>    multi_v7_defconfig to include the Kona watchdog to provide proper
>>> reboot for the
>>>    Broadcom Kona platforms
>>>
>>> Please note that Tejun Heo has queued a patch which renames
>>> AHCI_BRCMSTB into
>>> AHCI_BRCM, to avoid two patches in a row, we just enable AHCI_BRCM to
>>> be future
>>> proof
>>
>> So, you say that bcm_defconfig is no longer useful. While I'm happy to
>> see the
>> number of defconfigs go down, I'd like to clarify that we do still see
>> per-SoC
>> defconfigs somewhat useful, in that they are a lot closer to what
>> someone would
>> want to use for defconfig in a product kernel based on the SoC. It's
>> easier to
>> start from the SoC-specific defconfig and remove pieces that aren't
>> needed than
>> to start from multi_v7_defconfig.
> I completely agree that per-SoC defconfigs are extremely useful. I
> attempted to do so for Cygnus and would like to for other Broadcom SoCs
> as well. Unfortunately Arnd's policy was one defconfig per company. This
> prevents use from doing so. Broadcom has a variety of SoCs and families.
> Some share technology, others are entirely different. On the projects I
> work with we don't use multi_v7_defconfig nor do our customers. We use
> per SoC defconfigs.
> 
> So, as it stands bcm_defconfig is of little use to us. We are able to
> upstream everything into the kernel except for the defconfig file. We
> are forced to maintain these internally. Yet we are able to upstream dts
> files which are per board...

I really think the job of building an appropriate .config file for your
platform belongs in the build system you are utilizing. There could be
user-visible option that you allow people to turn on/off (e.g: kernels'
frace along with user-space profiling tools etc.), and in general build
systems enable a bunch of generic options shared across all targets they
support, and they just maintain relevant fragments for the specific
targets you build for, making the defconfig more or less contained
within the build system, and under control.

Maintaining a defconfig file is both boring and a great deal of pain
when trying to resolve conflicts, and keep in mind that the upstream
community can nitpick on every single change you enable/disable in there ;)
-- 
Florian