[U-Boot-Users] [PATCH] Move conditional compilation of MPC8XXX SPI driver to Makefile

[Wolfgang Denk]

In message <20080527100426.0f40544e at hskinnemo-gx745.norway.atmel.com> you wrote:
>
> > If we define CONFIG_HARD_SPI, then I don't see why CONFIG_MPC8XXX_SPI
> > is needed at all if we're on a MPC8XXX system - that seems  redundant
> > to  me.  On the other hand, if you want to use CONFIG_MPC8XXX_SPI and
> > this implies that CONFIG_HARD_SPI must be set, too,  then  it  should
> > automatically  set  this  variable  instead of causing the compile to
> > fail.
> 
> Sounds to me like you're asking for Kconfig. I can't think of any way
> to meet those requirements with the current infrastructure...

No? Uuups... what's wrong with

	#ifdef CONFIG_MPC8XXX_SPI
	# ifndef CONFIG_HARD_SPI
	#  define CONFIG_HARD_SPI
	# endif
	#endif

Not exactly beautiful, but should work, shouldn't it?

> To be more specific:
>   * Which part of the system is responsible for figuring out that when
>     CONFIG_HARD_SPI is set _and_ we're on a MPC8XXX system, the
>     mpx8xxx_spi driver should be compiled?

The Makefile?

Yes, you ill have to use a conditional in the Makefile as long as you
ask for separate CONFIG_ options. That's one reason why I'm asking why
we need several.

>   * Which part of the system is responsible for automatically selecting
>     CONFIG_HARD_SPI when CONFIG_MPC8XXX_SPI is set?

include/spi.h ?

> On the other hand, it looks like everyone but powerpc is getting away
> with not using CONFIG_HARD_SPI at all. Is it really necessary to have
> two defines for essentially the same thing?

Bingo! That was exactly my question.

> > This assumes that we use only one SPI  controller  (built-in  on  the
> > CPU/SOC).  We  should  also  keep  in  mind what happens when you use
> > CONFIG_SOFT_SPI, eventually even simultaneously.
> 
> The current infrastructure doesn't allow multiple SPI controllers.

Yes, I know. But we should keep in mind that one day  such  a  system
may  have  to be supported, and we should try not to make support for
such systems more difficult than necessary.

> The new infrastructure that I posted yesterday supports multiple SPI
> controllers of the same type, but not different ones. I asked whether
> supporting multiple different SPI controllers would be necessary but
> got no response, so I assumed no.

I think that's a valid assumption, at least for now. I cannot imagine
why multiple different SPI controllers might be needed, but then  I'm
surprised  again  and again what hardware designers can come up with.
So we should try not to build barriers that can be avoided.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Generally speaking, there are other ways to accomplish whatever it is
that you think you need ...                               - Doug Gwyn