On Wed, Oct 21, 2015 at 05:22:47PM -0700, Stephen Boyd wrote:

On 10/15, Scott Branden wrote:

quoted

On 15-10-15 02:15 PM, Ray Jui wrote:

quoted

On 10/15/2015 2:10 PM, Jon Mason wrote:

quoted

On Thu, Oct 15, 2015 at 02:04:09PM -0700, Scott Branden wrote:

quoted

On 15-10-15 01:55 PM, Ray Jui wrote:

quoted

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.

I'll do a pass at this today and send it out for review.

Thanks,
Jon

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project