Message ID | 1459540776-7056-1-git-send-email-andy.gross@linaro.org |
---|---|
State | New |
Headers | show |
On Fri, Apr 01, 2016 at 02:59:36PM -0500, Andy Gross wrote: > The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: > > Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.7 Are you sure? Last branch was all drivers/soc contents, which _I_ merged into next/drivers. This is all arch/arm contents, which _I_ would merge into next/soc. :) > for you to fetch changes up to d24a7dab5b8fa6717d7a3917a634b561dcee312f: > > ARM: qcom: Drop ARCH_MSM* configs (2016-03-31 17:37:31 -0500) > > ---------------------------------------------------------------- > Qualcomm ARM Based Driver Updates for v4.7 > > * Drop ARCH_MSM* configs and fixup clocksource support > > ---------------------------------------------------------------- > Stephen Boyd (2): > ARM: qcom: Make an option for qcom 'a-family' platforms > ARM: qcom: Drop ARCH_MSM* configs THis does: -config ARCH_MSM8974 - bool "Enable support for MSM8974" - select HAVE_ARM_ARCH_TIMER ... and I don't see the HAVE_ARCH_ARM_TIMER added anywhere. So it looks like you might need to pick it for ARCH_QCOM_A_FAMILY now? -Olof
On 04/13, Olof Johansson wrote: > THis does: > > -config ARCH_MSM8974 > - bool "Enable support for MSM8974" > - select HAVE_ARM_ARCH_TIMER > > > ... and I don't see the HAVE_ARCH_ARM_TIMER added anywhere. So it looks > like you might need to pick it for ARCH_QCOM_A_FAMILY now? > That was part of the original series[1]. Splitting up patches into topic branches is problematic here it seems. [1] http://lkml.kernel.org/r/1448485478-21699-3-git-send-email-sboyd@codeaurora.org
On Wed, Apr 13, 2016 at 11:21:56AM -0700, Stephen Boyd wrote: > On 04/13, Olof Johansson wrote: > > THis does: > > > > -config ARCH_MSM8974 > > - bool "Enable support for MSM8974" > > - select HAVE_ARM_ARCH_TIMER > > > > > > ... and I don't see the HAVE_ARCH_ARM_TIMER added anywhere. So it looks > > like you might need to pick it for ARCH_QCOM_A_FAMILY now? > > > > That was part of the original series[1]. Splitting up patches > into topic branches is problematic here it seems. > > [1] http://lkml.kernel.org/r/1448485478-21699-3-git-send-email-sboyd@codeaurora.org The HAVE.* options are usually expected to be set through selects, not necessarily driven by a user choosing them. So I think adding a select here is the right way to do it. HAVE.* options are usually used for dependencies for the user-exposed options. I.e. only ask if you want arch timers if HAVE_ARM_ARCH_TIMERS is set, etc. -Olof
On 04/13, Olof Johansson wrote: > On Wed, Apr 13, 2016 at 11:21:56AM -0700, Stephen Boyd wrote: > > That was part of the original series[1]. Splitting up patches > > into topic branches is problematic here it seems. > > > > [1] http://lkml.kernel.org/r/1448485478-21699-3-git-send-email-sboyd@codeaurora.org > > The HAVE.* options are usually expected to be set through selects, not > necessarily driven by a user choosing them. So I think adding a select here is > the right way to do it. > > HAVE.* options are usually used for dependencies for the user-exposed options. > I.e. only ask if you want arch timers if HAVE_ARM_ARCH_TIMERS is set, etc. > Agreed. Perhaps the name is bad? I don't know the history of the Kconfig, but HAVE_ARM_ARCH_TIMER is a user visible option, so selecting it in Kconfig language doesn't make much sense to me. Some other platforms are following the same design where it's part of the defconfig while others are selecting it from Kconfig. Mass confusion has set in. If we want to change the design to be selected by all platforms then we'll need to make HAVE_ARM_ARCH_TIMER into a hidden Kconfig option so that users can't turn it off. In fact, we may want to just obliterate the Kconfig entirely and have users select ARM_ARCH_TIMER directly. Everything is multi-platform now, right? If so then GENERIC_CLOCKEVENTS is selected all the time on CPU_V7 and the CPU_V7 dependency is not helping much. Honestly, I view these clocksource selects as the only blocker in the effort to get rid of machine type Kconfigs. Maybe that isn't a good goal though.