| Message ID | 1466128575-5378-6-git-send-email-f.fainelli@gmail.com |
|---|---|
| State | New |
| Headers | show |
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. 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
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
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 ;)
On Mon, Jun 20, 2016 at 2:43 PM, Scott Branden <scott.branden@broadcom.com> 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. Yeah, I'm with Arnd on this in general; we can't do a crazy number of defconfigs -- which is why I said it's a starting point for further paring down. Still, given the variety of platforms from Broadcom it's likely too broad to be useful. Removing it makes sense. > 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... There's a huge difference in the cost of carrying a defconfig vs a dts file. A dts file is very cheap to compile and carry, while each defconfig adds a significant amount of time spent on build coverage. -Olof
HI Olof, On 16-06-20 03:04 PM, Olof Johansson wrote: > On Mon, Jun 20, 2016 at 2:43 PM, Scott Branden > <scott.branden@broadcom.com> 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. > > Yeah, I'm with Arnd on this in general; we can't do a crazy number of > defconfigs -- which is why I said it's a starting point for further > paring down. Still, given the variety of platforms from Broadcom it's > likely too broad to be useful. Removing it makes sense. I have been attempting to add Kconfig defaults to new drivers we are upstreaming. That way if a driver is used for an SoC family you simply can select the SoC family and voila the drivers are all default selected for you. An added benefit is we don't need to submit patches for multi_v7_defconfig every time we upstream a new driver. The drivers are automatically selected via the Kconfig. If this was promoted in the Kconfig files then all the other SoC specific defconfig files could be removed. All information about the SoC would be contained in the kernel instead of being maintained elsewhere. The user could generate any defconfig for their specific SoC(s) and the only paring down to be done would be limited to removing drivers that they don't use on their specific SoC. I have not added defaults for existing drivers - but if acceptable may do so at some time. This may make a long list of defaults for popular drivers, but it makes things far more maintainable than multiple defconfigs or burying SoC kernel specifics in a build system. > >> 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... > > There's a huge difference in the cost of carrying a defconfig vs a dts > file. A dts file is very cheap to compile and carry, while each > defconfig adds a significant amount of time spent on build coverage. Perhaps the build coverage should only be for multi_v7_defconfig and a big endian build version of it? > > > -Olof > Thanks, Scott
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 ---------------------------------------------------------------- Florian Fainelli (7): ARM: multi_v7_defconfig: Enable BCM63xx ARM: multi_v7_defconfig: Enable BRCMSTB networking ARM: multi_v7_defconfig: Enable Broadcom AHCI ARM: multi_v7_defconfig: Enable BCM7038 Watchdog ARM: multi_v7_defconfig: Enable Broadcom STB PWM ARM: multi_v7_defconfig: Enable Broadcom Kona watchdog ARM: Remove bcm_defconfig arch/arm/configs/bcm_defconfig | 141 ------------------------------------ arch/arm/configs/multi_v7_defconfig | 13 ++++ 2 files changed, 13 insertions(+), 141 deletions(-) delete mode 100644 arch/arm/configs/bcm_defconfig