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

Haavard Skinnemoen haavard.skinnemoen at atmel.com
Tue May 27 10:04:26 CEST 2008


Wolfgang Denk <wd at denx.de> wrote:
> In message <20080527093432.3026cb15 at hskinnemo-gx745.norway.atmel.com> you wrote:
> >
> > This only makes a difference if a board config defines
> > CONFIG_MPC8XXX_SPI without defining CONFIG_HARD_SPI, which is arguably
> > a bug. I think it's better to get a compile error when this happens
> 
> I can't really folow that logic.
> 
> 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...

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?
  * Which part of the system is responsible for automatically selecting
    CONFIG_HARD_SPI when CONFIG_MPC8XXX_SPI is set?

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?

> 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.

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.

Haavard




More information about the U-Boot mailing list