* [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk [not found] <CALAqxLVn9r9R-wnrZbrFqYfwqZD-tegbJrZLsUeBjjBc4_Q89w@mail.gmail.com> @ 2017-06-05 18:13 ` Daniel Lezcano 2017-06-06 14:17 ` Ulf Hansson 0 siblings, 1 reply; 12+ messages in thread From: Daniel Lezcano @ 2017-06-05 18:13 UTC (permalink / raw) To: catalin.marinas, will.deacon Cc: daniel.lezcano, John Stultz, Ulf Hansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list With the addition of the hi655x common clock, the config option is missing for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because the hi655x clock driver misses when initializing the power sequence via DT. Cc: John Stultz <john.stultz@linaro.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 73272f4..6dfe72c 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -79,6 +79,7 @@ config ARCH_LG1K config ARCH_HISI bool "Hisilicon SoC Family" select ARM_TIMER_SP804 + select COMMON_CLK_HI655X select HISILICON_IRQ_MBIGEN if PCI select PINCTRL help -- 2.7.4 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-05 18:13 ` [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk Daniel Lezcano @ 2017-06-06 14:17 ` Ulf Hansson 2017-06-09 15:46 ` Daniel Lezcano 0 siblings, 1 reply; 12+ messages in thread From: Ulf Hansson @ 2017-06-06 14:17 UTC (permalink / raw) To: Daniel Lezcano Cc: Catalin Marinas, Will Deacon, John Stultz, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > With the addition of the hi655x common clock, the config option is missing > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because > the hi655x clock driver misses when initializing the power sequence via DT. > > Cc: John Stultz <john.stultz@linaro.org> > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Wei Xu <xuwei5@hisilicon.com> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi work for Hikey. Kind regards Uffe > --- > arch/arm64/Kconfig.platforms | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 73272f4..6dfe72c 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -79,6 +79,7 @@ config ARCH_LG1K > config ARCH_HISI > bool "Hisilicon SoC Family" > select ARM_TIMER_SP804 > + select COMMON_CLK_HI655X > select HISILICON_IRQ_MBIGEN if PCI > select PINCTRL > help > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-06 14:17 ` Ulf Hansson @ 2017-06-09 15:46 ` Daniel Lezcano 2017-06-09 20:06 ` Arnd Bergmann 0 siblings, 1 reply; 12+ messages in thread From: Daniel Lezcano @ 2017-06-09 15:46 UTC (permalink / raw) To: Ulf Hansson Cc: Catalin Marinas, Will Deacon, Olof Johansson, Arnd Bergmann, John Stultz, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Tue, Jun 06, 2017 at 04:17:40PM +0200, Ulf Hansson wrote: > On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > > With the addition of the hi655x common clock, the config option is missing > > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because > > the hi655x clock driver misses when initializing the power sequence via DT. > > > > Cc: John Stultz <john.stultz@linaro.org> > > Cc: Ulf Hansson <ulf.hansson@linaro.org> > > Cc: Wei Xu <xuwei5@hisilicon.com> > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > > Acked-by: Ulf Hansson <ulf.hansson@linaro.org> > > Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi > work for Hikey. > I'm wondering if I submitted this patch for the right path. Shall it go through arm-soc ? +Olof, +Arnd > > > --- > > arch/arm64/Kconfig.platforms | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > > index 73272f4..6dfe72c 100644 > > --- a/arch/arm64/Kconfig.platforms > > +++ b/arch/arm64/Kconfig.platforms > > @@ -79,6 +79,7 @@ config ARCH_LG1K > > config ARCH_HISI > > bool "Hisilicon SoC Family" > > select ARM_TIMER_SP804 > > + select COMMON_CLK_HI655X > > select HISILICON_IRQ_MBIGEN if PCI > > select PINCTRL > > help > > -- > > 2.7.4 > > -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-09 15:46 ` Daniel Lezcano @ 2017-06-09 20:06 ` Arnd Bergmann 2017-06-09 20:15 ` John Stultz 0 siblings, 1 reply; 12+ messages in thread From: Arnd Bergmann @ 2017-06-09 20:06 UTC (permalink / raw) To: Daniel Lezcano Cc: Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, John Stultz, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > On Tue, Jun 06, 2017 at 04:17:40PM +0200, Ulf Hansson wrote: >> On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: >> > With the addition of the hi655x common clock, the config option is missing >> > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because >> > the hi655x clock driver misses when initializing the power sequence via DT. >> > >> > Cc: John Stultz <john.stultz@linaro.org> >> > Cc: Ulf Hansson <ulf.hansson@linaro.org> >> > Cc: Wei Xu <xuwei5@hisilicon.com> >> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> >> >> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> >> >> Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi >> work for Hikey. >> > > I'm wondering if I submitted this patch for the right path. > > Shall it go through arm-soc ? Yes, but I'm not sure this is the right patch either. We tend to not use 'select' for user-visible drivers, and most hisilicon platforms won't need this driver. I think it would be more consistent to add this to the defconfig and regard it as a user error when the driver is disabled on a machine that needs it. Arnd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-09 20:06 ` Arnd Bergmann @ 2017-06-09 20:15 ` John Stultz 2017-06-09 20:48 ` Arnd Bergmann 0 siblings, 1 reply; 12+ messages in thread From: John Stultz @ 2017-06-09 20:15 UTC (permalink / raw) To: Arnd Bergmann Cc: Daniel Lezcano, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: >> On Tue, Jun 06, 2017 at 04:17:40PM +0200, Ulf Hansson wrote: >>> On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: >>> > With the addition of the hi655x common clock, the config option is missing >>> > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because >>> > the hi655x clock driver misses when initializing the power sequence via DT. >>> > >>> > Cc: John Stultz <john.stultz@linaro.org> >>> > Cc: Ulf Hansson <ulf.hansson@linaro.org> >>> > Cc: Wei Xu <xuwei5@hisilicon.com> >>> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> >>> >>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> >>> >>> Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi >>> work for Hikey. >>> >> >> I'm wondering if I submitted this patch for the right path. >> >> Shall it go through arm-soc ? > > Yes, but I'm not sure this is the right patch either. We tend to not > use 'select' for user-visible drivers, and most hisilicon platforms > won't need this driver. > > I think it would be more consistent to add this to the defconfig > and regard it as a user error when the driver is disabled on a > machine that needs it. Maybe the select is not exactly in the right place, but I don't really feel like a pmic on an SoC is a "user-visible driver". I deal with the board often and when the new dependency was made on the clk, I would have never have found it on my own w/o Ulf and Daniel pointing out what I needed to enable. thanks -john ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-09 20:15 ` John Stultz @ 2017-06-09 20:48 ` Arnd Bergmann 2017-06-12 9:38 ` Daniel Lezcano 0 siblings, 1 reply; 12+ messages in thread From: Arnd Bergmann @ 2017-06-09 20:48 UTC (permalink / raw) To: John Stultz Cc: Daniel Lezcano, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: > On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >> <daniel.lezcano@linaro.org> wrote: >>> On Tue, Jun 06, 2017 at 04:17:40PM +0200, Ulf Hansson wrote: >>>> On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: >>>> > With the addition of the hi655x common clock, the config option is missing >>>> > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because >>>> > the hi655x clock driver misses when initializing the power sequence via DT. >>>> > >>>> > Cc: John Stultz <john.stultz@linaro.org> >>>> > Cc: Ulf Hansson <ulf.hansson@linaro.org> >>>> > Cc: Wei Xu <xuwei5@hisilicon.com> >>>> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> >>>> >>>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> >>>> >>>> Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi >>>> work for Hikey. >>>> >>> >>> I'm wondering if I submitted this patch for the right path. >>> >>> Shall it go through arm-soc ? >> >> Yes, but I'm not sure this is the right patch either. We tend to not >> use 'select' for user-visible drivers, and most hisilicon platforms >> won't need this driver. >> >> I think it would be more consistent to add this to the defconfig >> and regard it as a user error when the driver is disabled on a >> machine that needs it. > > Maybe the select is not exactly in the right place, but I don't really > feel like a pmic on an SoC is a "user-visible driver". I deal with the > board often and when the new dependency was made on the clk, I would > have never have found it on my own w/o Ulf and Daniel pointing out > what I needed to enable. What I meant is that the Kconfig option is user-visible. On a very high level, this is a result of arch/arm64/Kconfig.platforms listing only very broad categories of SoCs, in many cases only the manufacturers of very different chip families, which then control the visibility of the individual Kconfig items for things like pinctrl or clk. I now see that MFD_HI655X_PMIC is the top-level driver that you have to select before enabling COMMON_CLK_HI655X, so the patch is actually broken unless it actually selects both. How about simply adding a 'default MFD_HI655X_PMIC' to COMMON_CLK_HI655X to enable it unless it is explicitly turned off? Arnd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-09 20:48 ` Arnd Bergmann @ 2017-06-12 9:38 ` Daniel Lezcano 2017-06-12 21:12 ` Arnd Bergmann 0 siblings, 1 reply; 12+ messages in thread From: Daniel Lezcano @ 2017-06-12 9:38 UTC (permalink / raw) To: Arnd Bergmann Cc: John Stultz, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: > On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: > > On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: > >> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano > >> <daniel.lezcano@linaro.org> wrote: > >>> On Tue, Jun 06, 2017 at 04:17:40PM +0200, Ulf Hansson wrote: > >>>> On 5 June 2017 at 20:13, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > >>>> > With the addition of the hi655x common clock, the config option is missing > >>>> > for the ARM64's hi6220 platform. That leads to a non functionnal WiFi because > >>>> > the hi655x clock driver misses when initializing the power sequence via DT. > >>>> > > >>>> > Cc: John Stultz <john.stultz@linaro.org> > >>>> > Cc: Ulf Hansson <ulf.hansson@linaro.org> > >>>> > Cc: Wei Xu <xuwei5@hisilicon.com> > >>>> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > >>>> > >>>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> > >>>> > >>>> Would be nice to get this trivial fix in for 4.12 rcs to make the WiFi > >>>> work for Hikey. > >>>> > >>> > >>> I'm wondering if I submitted this patch for the right path. > >>> > >>> Shall it go through arm-soc ? > >> > >> Yes, but I'm not sure this is the right patch either. We tend to not > >> use 'select' for user-visible drivers, and most hisilicon platforms > >> won't need this driver. > >> > >> I think it would be more consistent to add this to the defconfig > >> and regard it as a user error when the driver is disabled on a > >> machine that needs it. > > > > Maybe the select is not exactly in the right place, but I don't really > > feel like a pmic on an SoC is a "user-visible driver". I deal with the > > board often and when the new dependency was made on the clk, I would > > have never have found it on my own w/o Ulf and Daniel pointing out > > what I needed to enable. > > What I meant is that the Kconfig option is user-visible. On a very high > level, this is a result of arch/arm64/Kconfig.platforms listing only > very broad categories of SoCs, in many cases only the manufacturers > of very different chip families, which then control the visibility of the > individual Kconfig items for things like pinctrl or clk. > > I now see that MFD_HI655X_PMIC is the top-level driver that you > have to select before enabling COMMON_CLK_HI655X, so the > patch is actually broken unless it actually selects both. > > How about simply adding a 'default MFD_HI655X_PMIC' to > COMMON_CLK_HI655X to enable it unless it is explicitly > turned off? Actually, I share John's opinion. Ideally when we choose a platform, all the relevants devices configuration options should be selected automatically from a single topmost node of a tree (platform selection) to all the nodes corresponding to the devices, leaving the user to select one simple option without knowledge of the SoC hardware internals. If the user is expert in the platform and knows exactly what he does, then he can select an _EXPERT_ like option and be able to disable some drivers. It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when MFD_HI655X_PMIC is enabled? -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-12 9:38 ` Daniel Lezcano @ 2017-06-12 21:12 ` Arnd Bergmann 2017-06-13 12:48 ` Daniel Lezcano 2018-02-16 17:35 ` Daniel Lezcano 0 siblings, 2 replies; 12+ messages in thread From: Arnd Bergmann @ 2017-06-12 21:12 UTC (permalink / raw) To: Daniel Lezcano Cc: John Stultz, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On Mon, Jun 12, 2017 at 11:38 AM, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: >> On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: >> > On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >> >> <daniel.lezcano@linaro.org> wrote: >> >> >> >> Yes, but I'm not sure this is the right patch either. We tend to not >> >> use 'select' for user-visible drivers, and most hisilicon platforms >> >> won't need this driver. >> >> >> >> I think it would be more consistent to add this to the defconfig >> >> and regard it as a user error when the driver is disabled on a >> >> machine that needs it. >> > >> > Maybe the select is not exactly in the right place, but I don't really >> > feel like a pmic on an SoC is a "user-visible driver". I deal with the >> > board often and when the new dependency was made on the clk, I would >> > have never have found it on my own w/o Ulf and Daniel pointing out >> > what I needed to enable. >> >> What I meant is that the Kconfig option is user-visible. On a very high >> level, this is a result of arch/arm64/Kconfig.platforms listing only >> very broad categories of SoCs, in many cases only the manufacturers >> of very different chip families, which then control the visibility of the >> individual Kconfig items for things like pinctrl or clk. >> >> I now see that MFD_HI655X_PMIC is the top-level driver that you >> have to select before enabling COMMON_CLK_HI655X, so the >> patch is actually broken unless it actually selects both. >> >> How about simply adding a 'default MFD_HI655X_PMIC' to >> COMMON_CLK_HI655X to enable it unless it is explicitly >> turned off? > > Actually, I share John's opinion. > > Ideally when we choose a platform, all the relevants devices configuration > options should be selected automatically from a single topmost node of a tree > (platform selection) to all the nodes corresponding to the devices, leaving the > user to select one simple option without knowledge of the SoC hardware > internals. > > If the user is expert in the platform and knows exactly what he does, then he > can select an _EXPERT_ like option and be able to disable some drivers. > > It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' > is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when > MFD_HI655X_PMIC is enabled? I don't think it's that easy. When you do that, MFD_HI655X_PMIC gains a dependency on COMMON_CLK and will again cause a warning on machines that disable that during compile testing. Using 'select' for user-selectable options generally leads to problems, and you are better off avoiding it. If you want to make the symbol impossible to turn off for non-EXPERT configurations, you can write it like config COMMON_CLK_HI655X tristate "Clock driver for Hi655x" if EXPERT depends on (MFD_HI655X_PMIC || COMPILE_TEST) depends on REGMAP default MFD_HI655X_PMIC That way the option is completely hidden for non-EXPERT, but still has the right default otherwise, and the dependencies are tracked right for compile-testing. Arnd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-12 21:12 ` Arnd Bergmann @ 2017-06-13 12:48 ` Daniel Lezcano 2018-02-16 17:35 ` Daniel Lezcano 1 sibling, 0 replies; 12+ messages in thread From: Daniel Lezcano @ 2017-06-13 12:48 UTC (permalink / raw) To: Arnd Bergmann Cc: John Stultz, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On 12/06/2017 23:12, Arnd Bergmann wrote: > On Mon, Jun 12, 2017 at 11:38 AM, Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: >> On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: >>> On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: >>>> On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>>>> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >>>>> <daniel.lezcano@linaro.org> wrote: >>>>> >>>>> Yes, but I'm not sure this is the right patch either. We tend to not >>>>> use 'select' for user-visible drivers, and most hisilicon platforms >>>>> won't need this driver. >>>>> >>>>> I think it would be more consistent to add this to the defconfig >>>>> and regard it as a user error when the driver is disabled on a >>>>> machine that needs it. >>>> >>>> Maybe the select is not exactly in the right place, but I don't really >>>> feel like a pmic on an SoC is a "user-visible driver". I deal with the >>>> board often and when the new dependency was made on the clk, I would >>>> have never have found it on my own w/o Ulf and Daniel pointing out >>>> what I needed to enable. >>> >>> What I meant is that the Kconfig option is user-visible. On a very high >>> level, this is a result of arch/arm64/Kconfig.platforms listing only >>> very broad categories of SoCs, in many cases only the manufacturers >>> of very different chip families, which then control the visibility of the >>> individual Kconfig items for things like pinctrl or clk. >>> >>> I now see that MFD_HI655X_PMIC is the top-level driver that you >>> have to select before enabling COMMON_CLK_HI655X, so the >>> patch is actually broken unless it actually selects both. >>> >>> How about simply adding a 'default MFD_HI655X_PMIC' to >>> COMMON_CLK_HI655X to enable it unless it is explicitly >>> turned off? >> >> Actually, I share John's opinion. >> >> Ideally when we choose a platform, all the relevants devices configuration >> options should be selected automatically from a single topmost node of a tree >> (platform selection) to all the nodes corresponding to the devices, leaving the >> user to select one simple option without knowledge of the SoC hardware >> internals. >> >> If the user is expert in the platform and knows exactly what he does, then he >> can select an _EXPERT_ like option and be able to disable some drivers. >> >> It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' >> is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when >> MFD_HI655X_PMIC is enabled? > > I don't think it's that easy. When you do that, MFD_HI655X_PMIC gains > a dependency on COMMON_CLK and will again cause a warning on > machines that disable that during compile testing. This issue is related to the missing stubs in the includes. > Using 'select' for user-selectable options generally leads to problems, > and you are better off avoiding it. If you want to make the symbol impossible > to turn off for non-EXPERT configurations, you can write it like > > config COMMON_CLK_HI655X > tristate "Clock driver for Hi655x" if EXPERT > depends on (MFD_HI655X_PMIC || COMPILE_TEST) > depends on REGMAP > default MFD_HI655X_PMIC > > That way the option is completely hidden for non-EXPERT, > but still has the right default otherwise, and the dependencies > are tracked right for compile-testing. Ok. Thanks! -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2017-06-12 21:12 ` Arnd Bergmann 2017-06-13 12:48 ` Daniel Lezcano @ 2018-02-16 17:35 ` Daniel Lezcano 2018-02-21 10:30 ` Riku Voipio 1 sibling, 1 reply; 12+ messages in thread From: Daniel Lezcano @ 2018-02-16 17:35 UTC (permalink / raw) To: Arnd Bergmann Cc: John Stultz, Ulf Hansson, Catalin Marinas, Will Deacon, Olof Johansson, Wei Xu, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list On 12/06/2017 23:12, Arnd Bergmann wrote: > On Mon, Jun 12, 2017 at 11:38 AM, Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: >> On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: >>> On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: >>>> On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>>>> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >>>>> <daniel.lezcano@linaro.org> wrote: >>>>> >>>>> Yes, but I'm not sure this is the right patch either. We tend to not >>>>> use 'select' for user-visible drivers, and most hisilicon platforms >>>>> won't need this driver. >>>>> >>>>> I think it would be more consistent to add this to the defconfig >>>>> and regard it as a user error when the driver is disabled on a >>>>> machine that needs it. >>>> >>>> Maybe the select is not exactly in the right place, but I don't really >>>> feel like a pmic on an SoC is a "user-visible driver". I deal with the >>>> board often and when the new dependency was made on the clk, I would >>>> have never have found it on my own w/o Ulf and Daniel pointing out >>>> what I needed to enable. >>> >>> What I meant is that the Kconfig option is user-visible. On a very high >>> level, this is a result of arch/arm64/Kconfig.platforms listing only >>> very broad categories of SoCs, in many cases only the manufacturers >>> of very different chip families, which then control the visibility of the >>> individual Kconfig items for things like pinctrl or clk. >>> >>> I now see that MFD_HI655X_PMIC is the top-level driver that you >>> have to select before enabling COMMON_CLK_HI655X, so the >>> patch is actually broken unless it actually selects both. >>> >>> How about simply adding a 'default MFD_HI655X_PMIC' to >>> COMMON_CLK_HI655X to enable it unless it is explicitly >>> turned off? >> >> Actually, I share John's opinion. >> >> Ideally when we choose a platform, all the relevants devices configuration >> options should be selected automatically from a single topmost node of a tree >> (platform selection) to all the nodes corresponding to the devices, leaving the >> user to select one simple option without knowledge of the SoC hardware >> internals. >> >> If the user is expert in the platform and knows exactly what he does, then he >> can select an _EXPERT_ like option and be able to disable some drivers. >> >> It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' >> is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when >> MFD_HI655X_PMIC is enabled? > > I don't think it's that easy. When you do that, MFD_HI655X_PMIC gains > a dependency on COMMON_CLK and will again cause a warning on > machines that disable that during compile testing. > > Using 'select' for user-selectable options generally leads to problems, > and you are better off avoiding it. If you want to make the symbol impossible > to turn off for non-EXPERT configurations, you can write it like > > config COMMON_CLK_HI655X > tristate "Clock driver for Hi655x" if EXPERT > depends on (MFD_HI655X_PMIC || COMPILE_TEST) > depends on REGMAP > default MFD_HI655X_PMIC > > That way the option is completely hidden for non-EXPERT, > but still has the right default otherwise, and the dependencies > are tracked right for compile-testing. What about the options: CONFIG_HI3660_MBOX CONFIG_HI6220_MBOX CONFIG_STUB_CLK_HI6220 CONFIG_STUB_CLK_HI3660 ? Would make sense to do something like: diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index b9546ab..3a07dfe 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -517,7 +517,6 @@ CONFIG_COMMON_CLK_CS2000_CP=y CONFIG_COMMON_CLK_S2MPS11=y CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y -CONFIG_STUB_CLK_HI3660=y CONFIG_COMMON_CLK_QCOM=y CONFIG_QCOM_CLK_SMD_RPM=y CONFIG_IPQ_GCC_8074=y @@ -529,8 +528,6 @@ CONFIG_HWSPINLOCK_QCOM=y CONFIG_ARM_MHU=y CONFIG_PLATFORM_MHU=y CONFIG_BCM2835_MBOX=y -CONFIG_HI3660_MBOX=y -CONFIG_HI6220_MBOX=y CONFIG_ROCKCHIP_IOMMU=y CONFIG_ARM_SMMU=y CONFIG_ARM_SMMU_V3=y diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig index 1bd4355..becdb1d 100644 --- a/drivers/clk/hisilicon/Kconfig +++ b/drivers/clk/hisilicon/Kconfig @@ -44,14 +44,17 @@ config RESET_HISI Build reset controller driver for HiSilicon device chipsets. config STUB_CLK_HI6220 - bool "Hi6220 Stub Clock Driver" - depends on COMMON_CLK_HI6220 && MAILBOX - default ARCH_HISI + bool "Hi6220 Stub Clock Driver" if EXPERT + depends on (COMMON_CLK_HI6220 || COMPILE_TEST) + depends on MAILBOX + default COMMON_CLK_HI6220 help Build the Hisilicon Hi6220 stub clock driver. config STUB_CLK_HI3660 - bool "Hi3660 Stub Clock Driver" - depends on COMMON_CLK_HI3660 && MAILBOX + bool "Hi3660 Stub Clock Driver" if EXPERT + depends on (COMMON_CLK_HI3660 || COMPILE_TEST) + depends on MAILBOX + default COMMON_CLK_HI3660 help Build the Hisilicon Hi3660 stub clock driver. diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index de8390d4..8d1726c 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -109,16 +109,19 @@ config TI_MESSAGE_MANAGER platform has support for the hardware block. config HI3660_MBOX - tristate "Hi3660 Mailbox" - depends on ARCH_HISI && OF + tristate "Hi3660 Mailbox" if EXPERT + depends on (ARCH_HISI || COMPILE_TEST) + depends on OF + default ARCH_HISI help An implementation of the hi3660 mailbox. It is used to send message between application processors and other processors/MCU/DSP. Select Y here if you want to use Hi3660 mailbox controller. config HI6220_MBOX - tristate "Hi6220 Mailbox" - depends on ARCH_HISI + tristate "Hi6220 Mailbox" if EXPERT + depends on (ARCH_HISI || COMPILE_TEST) + default ARCH_HISI help An implementation of the hi6220 mailbox. It is used to send message between application processors and MCU. Say Y here if you want to -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2018-02-16 17:35 ` Daniel Lezcano @ 2018-02-21 10:30 ` Riku Voipio 2018-02-21 10:34 ` Daniel Lezcano 0 siblings, 1 reply; 12+ messages in thread From: Riku Voipio @ 2018-02-21 10:30 UTC (permalink / raw) To: Daniel Lezcano Cc: Arnd Bergmann, Ulf Hansson, Catalin Marinas, Will Deacon, open list, Wei Xu, John Stultz, Olof Johansson, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE) On 16 February 2018 at 19:35, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > On 12/06/2017 23:12, Arnd Bergmann wrote: >> On Mon, Jun 12, 2017 at 11:38 AM, Daniel Lezcano >> <daniel.lezcano@linaro.org> wrote: >>> On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: >>>> On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: >>>>> On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>>>>> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >>>>>> <daniel.lezcano@linaro.org> wrote: >>>>>> >>>>>> Yes, but I'm not sure this is the right patch either. We tend to not >>>>>> use 'select' for user-visible drivers, and most hisilicon platforms >>>>>> won't need this driver. >>>>>> >>>>>> I think it would be more consistent to add this to the defconfig >>>>>> and regard it as a user error when the driver is disabled on a >>>>>> machine that needs it. >>>>> >>>>> Maybe the select is not exactly in the right place, but I don't really >>>>> feel like a pmic on an SoC is a "user-visible driver". I deal with the >>>>> board often and when the new dependency was made on the clk, I would >>>>> have never have found it on my own w/o Ulf and Daniel pointing out >>>>> what I needed to enable. >>>> >>>> What I meant is that the Kconfig option is user-visible. On a very high >>>> level, this is a result of arch/arm64/Kconfig.platforms listing only >>>> very broad categories of SoCs, in many cases only the manufacturers >>>> of very different chip families, which then control the visibility of the >>>> individual Kconfig items for things like pinctrl or clk. >>>> >>>> I now see that MFD_HI655X_PMIC is the top-level driver that you >>>> have to select before enabling COMMON_CLK_HI655X, so the >>>> patch is actually broken unless it actually selects both. >>>> >>>> How about simply adding a 'default MFD_HI655X_PMIC' to >>>> COMMON_CLK_HI655X to enable it unless it is explicitly >>>> turned off? >>> >>> Actually, I share John's opinion. >>> >>> Ideally when we choose a platform, all the relevants devices configuration >>> options should be selected automatically from a single topmost node of a tree >>> (platform selection) to all the nodes corresponding to the devices, leaving the >>> user to select one simple option without knowledge of the SoC hardware >>> internals. >>> >>> If the user is expert in the platform and knows exactly what he does, then he >>> can select an _EXPERT_ like option and be able to disable some drivers. >>> >>> It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' >>> is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when >>> MFD_HI655X_PMIC is enabled? >> >> I don't think it's that easy. When you do that, MFD_HI655X_PMIC gains >> a dependency on COMMON_CLK and will again cause a warning on >> machines that disable that during compile testing. >> >> Using 'select' for user-selectable options generally leads to problems, >> and you are better off avoiding it. If you want to make the symbol impossible >> to turn off for non-EXPERT configurations, you can write it like >> >> config COMMON_CLK_HI655X >> tristate "Clock driver for Hi655x" if EXPERT >> depends on (MFD_HI655X_PMIC || COMPILE_TEST) >> depends on REGMAP >> default MFD_HI655X_PMIC >> >> That way the option is completely hidden for non-EXPERT, >> but still has the right default otherwise, and the dependencies >> are tracked right for compile-testing. > > What about the options: First, as distros, automatic selection down from selecting ARCH_X is preferred over defconfigs. However, we also prefer to build everything possible as modules, so "default Y" is sometimes too strong. > CONFIG_HI3660_MBOX > CONFIG_HI6220_MBOX These are tristate and platorms can boot without them. > CONFIG_STUB_CLK_HI6220 > CONFIG_STUB_CLK_HI3660 These are bool, so default Y is ok. > Would make sense to do something like: > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index b9546ab..3a07dfe 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -517,7 +517,6 @@ CONFIG_COMMON_CLK_CS2000_CP=y > CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_CLK_QORIQ=y > CONFIG_COMMON_CLK_PWM=y > -CONFIG_STUB_CLK_HI3660=y > CONFIG_COMMON_CLK_QCOM=y > CONFIG_QCOM_CLK_SMD_RPM=y > CONFIG_IPQ_GCC_8074=y > @@ -529,8 +528,6 @@ CONFIG_HWSPINLOCK_QCOM=y > CONFIG_ARM_MHU=y > CONFIG_PLATFORM_MHU=y > CONFIG_BCM2835_MBOX=y > -CONFIG_HI3660_MBOX=y > -CONFIG_HI6220_MBOX=y > CONFIG_ROCKCHIP_IOMMU=y > CONFIG_ARM_SMMU=y > CONFIG_ARM_SMMU_V3=y > diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig > index 1bd4355..becdb1d 100644 > --- a/drivers/clk/hisilicon/Kconfig > +++ b/drivers/clk/hisilicon/Kconfig > @@ -44,14 +44,17 @@ config RESET_HISI > Build reset controller driver for HiSilicon device chipsets. > > config STUB_CLK_HI6220 > - bool "Hi6220 Stub Clock Driver" > - depends on COMMON_CLK_HI6220 && MAILBOX > - default ARCH_HISI > + bool "Hi6220 Stub Clock Driver" if EXPERT > + depends on (COMMON_CLK_HI6220 || COMPILE_TEST) > + depends on MAILBOX > + default COMMON_CLK_HI6220 > help > Build the Hisilicon Hi6220 stub clock driver. > > config STUB_CLK_HI3660 > - bool "Hi3660 Stub Clock Driver" > - depends on COMMON_CLK_HI3660 && MAILBOX > + bool "Hi3660 Stub Clock Driver" if EXPERT > + depends on (COMMON_CLK_HI3660 || COMPILE_TEST) > + depends on MAILBOX > + default COMMON_CLK_HI3660 > help > Build the Hisilicon Hi3660 stub clock driver. > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig > index de8390d4..8d1726c 100644 > --- a/drivers/mailbox/Kconfig > +++ b/drivers/mailbox/Kconfig > @@ -109,16 +109,19 @@ config TI_MESSAGE_MANAGER > platform has support for the hardware block. > > config HI3660_MBOX > - tristate "Hi3660 Mailbox" > - depends on ARCH_HISI && OF > + tristate "Hi3660 Mailbox" if EXPERT > + depends on (ARCH_HISI || COMPILE_TEST) > + depends on OF > + default ARCH_HISI > help > An implementation of the hi3660 mailbox. It is used to send message > between application processors and other processors/MCU/DSP. Select > Y here if you want to use Hi3660 mailbox controller. Which kernel tree is this from? I don't see this driver in mainline. > > config HI6220_MBOX > - tristate "Hi6220 Mailbox" > - depends on ARCH_HISI > + tristate "Hi6220 Mailbox" if EXPERT > + depends on (ARCH_HISI || COMPILE_TEST) > + default ARCH_HISI > help > An implementation of the hi6220 mailbox. It is used to send message > between application processors and MCU. Say Y here if you want to > > > > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk 2018-02-21 10:30 ` Riku Voipio @ 2018-02-21 10:34 ` Daniel Lezcano 0 siblings, 0 replies; 12+ messages in thread From: Daniel Lezcano @ 2018-02-21 10:34 UTC (permalink / raw) To: Riku Voipio Cc: Arnd Bergmann, Ulf Hansson, Catalin Marinas, Will Deacon, open list, Wei Xu, John Stultz, Olof Johansson, moderated list:ARM64 PORT (AARCH64 ARCHITECTURE) On 21/02/2018 11:30, Riku Voipio wrote: > On 16 February 2018 at 19:35, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: >> On 12/06/2017 23:12, Arnd Bergmann wrote: >>> On Mon, Jun 12, 2017 at 11:38 AM, Daniel Lezcano >>> <daniel.lezcano@linaro.org> wrote: >>>> On Fri, Jun 09, 2017 at 10:48:13PM +0200, Arnd Bergmann wrote: >>>>> On Fri, Jun 9, 2017 at 10:15 PM, John Stultz <john.stultz@linaro.org> wrote: >>>>>> On Fri, Jun 9, 2017 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>>>>>> On Fri, Jun 9, 2017 at 5:46 PM, Daniel Lezcano >>>>>>> <daniel.lezcano@linaro.org> wrote: >>>>>>> >>>>>>> Yes, but I'm not sure this is the right patch either. We tend to not >>>>>>> use 'select' for user-visible drivers, and most hisilicon platforms >>>>>>> won't need this driver. >>>>>>> >>>>>>> I think it would be more consistent to add this to the defconfig >>>>>>> and regard it as a user error when the driver is disabled on a >>>>>>> machine that needs it. >>>>>> >>>>>> Maybe the select is not exactly in the right place, but I don't really >>>>>> feel like a pmic on an SoC is a "user-visible driver". I deal with the >>>>>> board often and when the new dependency was made on the clk, I would >>>>>> have never have found it on my own w/o Ulf and Daniel pointing out >>>>>> what I needed to enable. >>>>> >>>>> What I meant is that the Kconfig option is user-visible. On a very high >>>>> level, this is a result of arch/arm64/Kconfig.platforms listing only >>>>> very broad categories of SoCs, in many cases only the manufacturers >>>>> of very different chip families, which then control the visibility of the >>>>> individual Kconfig items for things like pinctrl or clk. >>>>> >>>>> I now see that MFD_HI655X_PMIC is the top-level driver that you >>>>> have to select before enabling COMMON_CLK_HI655X, so the >>>>> patch is actually broken unless it actually selects both. >>>>> >>>>> How about simply adding a 'default MFD_HI655X_PMIC' to >>>>> COMMON_CLK_HI655X to enable it unless it is explicitly >>>>> turned off? >>>> >>>> Actually, I share John's opinion. >>>> >>>> Ideally when we choose a platform, all the relevants devices configuration >>>> options should be selected automatically from a single topmost node of a tree >>>> (platform selection) to all the nodes corresponding to the devices, leaving the >>>> user to select one simple option without knowledge of the SoC hardware >>>> internals. >>>> >>>> If the user is expert in the platform and knows exactly what he does, then he >>>> can select an _EXPERT_ like option and be able to disable some drivers. >>>> >>>> It is how I tend to write the Kconfig options, so the 'default MFD_HI655X_PMIC' >>>> is confusing for me. Wouldn't make sense to select COMMON_CLK_HI655X when >>>> MFD_HI655X_PMIC is enabled? >>> >>> I don't think it's that easy. When you do that, MFD_HI655X_PMIC gains >>> a dependency on COMMON_CLK and will again cause a warning on >>> machines that disable that during compile testing. >>> >>> Using 'select' for user-selectable options generally leads to problems, >>> and you are better off avoiding it. If you want to make the symbol impossible >>> to turn off for non-EXPERT configurations, you can write it like >>> >>> config COMMON_CLK_HI655X >>> tristate "Clock driver for Hi655x" if EXPERT >>> depends on (MFD_HI655X_PMIC || COMPILE_TEST) >>> depends on REGMAP >>> default MFD_HI655X_PMIC >>> >>> That way the option is completely hidden for non-EXPERT, >>> but still has the right default otherwise, and the dependencies >>> are tracked right for compile-testing. >> >> What about the options: > > First, as distros, automatic selection down from selecting ARCH_X is > preferred over > defconfigs. However, we also prefer to build everything possible as > modules, so "default Y" > is sometimes too strong. > >> CONFIG_HI3660_MBOX >> CONFIG_HI6220_MBOX > > These are tristate and platorms can boot without them. > >> CONFIG_STUB_CLK_HI6220 >> CONFIG_STUB_CLK_HI3660 > > These are bool, so default Y is ok. > >> Would make sense to do something like: > >> >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >> index b9546ab..3a07dfe 100644 >> --- a/arch/arm64/configs/defconfig >> +++ b/arch/arm64/configs/defconfig >> @@ -517,7 +517,6 @@ CONFIG_COMMON_CLK_CS2000_CP=y >> CONFIG_COMMON_CLK_S2MPS11=y >> CONFIG_CLK_QORIQ=y >> CONFIG_COMMON_CLK_PWM=y >> -CONFIG_STUB_CLK_HI3660=y >> CONFIG_COMMON_CLK_QCOM=y >> CONFIG_QCOM_CLK_SMD_RPM=y >> CONFIG_IPQ_GCC_8074=y >> @@ -529,8 +528,6 @@ CONFIG_HWSPINLOCK_QCOM=y >> CONFIG_ARM_MHU=y >> CONFIG_PLATFORM_MHU=y >> CONFIG_BCM2835_MBOX=y >> -CONFIG_HI3660_MBOX=y >> -CONFIG_HI6220_MBOX=y >> CONFIG_ROCKCHIP_IOMMU=y >> CONFIG_ARM_SMMU=y >> CONFIG_ARM_SMMU_V3=y >> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig >> index 1bd4355..becdb1d 100644 >> --- a/drivers/clk/hisilicon/Kconfig >> +++ b/drivers/clk/hisilicon/Kconfig >> @@ -44,14 +44,17 @@ config RESET_HISI >> Build reset controller driver for HiSilicon device chipsets. >> >> config STUB_CLK_HI6220 >> - bool "Hi6220 Stub Clock Driver" >> - depends on COMMON_CLK_HI6220 && MAILBOX >> - default ARCH_HISI >> + bool "Hi6220 Stub Clock Driver" if EXPERT >> + depends on (COMMON_CLK_HI6220 || COMPILE_TEST) >> + depends on MAILBOX >> + default COMMON_CLK_HI6220 >> help >> Build the Hisilicon Hi6220 stub clock driver. >> >> config STUB_CLK_HI3660 >> - bool "Hi3660 Stub Clock Driver" >> - depends on COMMON_CLK_HI3660 && MAILBOX >> + bool "Hi3660 Stub Clock Driver" if EXPERT >> + depends on (COMMON_CLK_HI3660 || COMPILE_TEST) >> + depends on MAILBOX >> + default COMMON_CLK_HI3660 >> help >> Build the Hisilicon Hi3660 stub clock driver. >> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig >> index de8390d4..8d1726c 100644 >> --- a/drivers/mailbox/Kconfig >> +++ b/drivers/mailbox/Kconfig >> @@ -109,16 +109,19 @@ config TI_MESSAGE_MANAGER >> platform has support for the hardware block. >> >> config HI3660_MBOX >> - tristate "Hi3660 Mailbox" >> - depends on ARCH_HISI && OF >> + tristate "Hi3660 Mailbox" if EXPERT >> + depends on (ARCH_HISI || COMPILE_TEST) >> + depends on OF >> + default ARCH_HISI >> help >> An implementation of the hi3660 mailbox. It is used to send message >> between application processors and other processors/MCU/DSP. Select >> Y here if you want to use Hi3660 mailbox controller. > > Which kernel tree is this from? I don't see this driver in mainline. Yes, that's right. The HI6220 part is ok but the HI3660 is still not mainline yet. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-02-21 10:34 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CALAqxLVn9r9R-wnrZbrFqYfwqZD-tegbJrZLsUeBjjBc4_Q89w@mail.gmail.com>
2017-06-05 18:13 ` [PATCH] ARM64: Kconfig: Fix the missing hi655x common clk Daniel Lezcano
2017-06-06 14:17 ` Ulf Hansson
2017-06-09 15:46 ` Daniel Lezcano
2017-06-09 20:06 ` Arnd Bergmann
2017-06-09 20:15 ` John Stultz
2017-06-09 20:48 ` Arnd Bergmann
2017-06-12 9:38 ` Daniel Lezcano
2017-06-12 21:12 ` Arnd Bergmann
2017-06-13 12:48 ` Daniel Lezcano
2018-02-16 17:35 ` Daniel Lezcano
2018-02-21 10:30 ` Riku Voipio
2018-02-21 10:34 ` Daniel Lezcano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox