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

[Scott Branden]

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...
>
> That being said, I'm happy to remove it if you think that's what works best for
> your platform.
>
> Merged into next/defconfig.
>
>
> -Olof
>
Regards,
  Scott