On Tue, Apr 12, 2022 at 12:35:42AM +0530, Pratyush Yadav wrote:
> On 08/04/22 10:47AM, Tom Rini wrote:
> > On Thu, Mar 31, 2022 at 03:35:26PM -0400, Tom Rini wrote:
> > 
> > > This is a little tricky since SoCFPGA has code to determine this as
> > > runtime.  Introduce a guard variable for platforms to select if they
> > > have a static value to use.  Then for ARCH_SOCFPGA, call
> > > cm_get_qspi_controller_clk_hz() and otherwise continue the previous
> > > behavior.
> > > 
> > > Cc: Jagan Teki <jagan@amarulasolutions.com>
> > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > 
> > OK, so there's a problem with using IS_ENABLED(..) which is that we get
> > a failure to build in the not-enabled case over CONFIG_CQSPI_REF_CLK
> > being unset.  And then we can't use if (CONFIG_VAL(..)) because we then
> > run in to needing it to exist for SPL as well.  I'm going to go back to
> > v1 of this particular patch.
> 
> Interesting! I remember trying the IS_ENABLED() thing a while back, and 
> I remember it working fine when the functions don't exist if the config 
> is not enabled. I figured that was because of the compiler eliminating 
> dead code. But I think here it is the preprocessor raising the error and 
> maybe it is not so smart. Dunno.
> 
> Anyway, I am fine with reverting this to v1 for now. I'll try to look at 
> it later if I ever get some time to spare.

Right, dead code elimination works fine since it's a reference to
function that's never called so we don't fail to link.  But if we don't
have a static value available, it fails to compile outright.  And there
wasn't a clean way I could see to use a default of 0 and have it work.
But the final part was that it was TI platforms, and I think just 2
others, that even set a static value here and you said TI ones should
just not set the value.  So I think the next reasonable clean-up might
be to just drop the static value case (and cc the board maintainers for
the other users), and only support the SoCFPGA one as being special.

-- 
Tom