On 10/15, Scott Branden wrote: > On 15-10-15 02:15 PM, Ray Jui wrote: > >On 10/15/2015 2:10 PM, Jon Mason wrote: > >>On Thu, Oct 15, 2015 at 02:04:09PM -0700, Scott Branden wrote: > >>>On 15-10-15 01:55 PM, Ray Jui wrote: > >>>>On 10/15/2015 1:40 PM, Scott Branden wrote: > >>>> > >>>>If using CONFIG_CLK_NS2, how is it going to be enabled/selected? > >>> > >>>Since CONFIG_ARCH_BCM_NS2 isn't "allowed" to be introduced we will > >>>need to create and select a CONFIG_CLK_BCM_NS2 in the defconfig > >>>instead. > >> > >>Is this better than the binary becoming slightly bigger? I thought > >>the extra complexity was worse than having an unused chunk of clk code > >>(and Kona is already doing the same thing above). I believe Ray was > >>in agreement with me during the internal review of this code. > >> > >>Thanks, > >>Jon > >> > > > >Yes, I'm okay with leaving it as it is. I even prefer changing the > >current Makefile to make all iProc based core clock drivers and SoC > >specific clock tables under CONFIG_COMMON_CLK_IPROC, which is what some > >of the other vendors do. > > > I'd leave it exactly as is then rather than pulling in more dead > code when not needed. This ns2 clock code is very minor compared to > other code bloat in the kernel and drivers.
We should really make these visible options that can be selected by anyone. Having selects in the ARCH config area is simple, but also has some downsides: 1) select is a reverse dependency and is hard for people to understand and can sometimes be a pain to track down 2) build coverage goes down because configs are hidden 3) we get code bloat like is being discussed here So I'd really like to see someone take a good look at this whole Makefile situation that's going on and clean it up so that they're user visible options and then throw the config options into the defconfig. It isn't going to block this series, but it would be nice to do at some later point. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
