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

[Ben Warren]

Sorry I'm just re-joining this conversation.  That's the fun of being
9 time zones apart...

On Tue, May 27, 2008 at 2:13 AM, Wolfgang Denk <wd at denx.de> wrote:
> In message <20080527103245.565527ba at hskinnemo-gx745.norway.atmel.com> you wrote:
>>
>> So maybe we should try to get rid of the CONFIG_HARD_SPI define? I
>
> Well, I think I'd rather get rid of  CONFIG_MPC8XXX_SPI  as  this  is
> redundant - it's what you atomatically get when using CONFIG_HARD_SPI
> on  a  MPC8XXX system. That would make this more in line with the I2C
> code. And we can use something like
>
>        #if defined(CONFIG_HARD_SPI) || defined (CONFIG_SOFT_SPI)
>
> when we need to know if there is any SPI support at all (like we do
> with I2C).
>

Ideally, we'd be able to re-claim CONFIG_SPI from whatever perverse
use it currently has (IIRC it CONFIG_BOOT_FROM_SPI_EEPROM), but that's
pretty invasive.
I don't think we want to take out CONFIG_MCP8XXX_SPI, because then
somebody needs to keep track of what CPUs have it and maintain the
header files appropriately.  I can just imagine the mess:

#if (defined MPC834X) || (defined MPC857X) || (defined MPC9766) || \
.
.
.
do your stuff
#endif

  Automatically generating CONFIG_HARD_SPI from it, though, makes
sense, though, although I hate to see architecture-specific stuff go
in spi.h.  NBD, I guess.

>> I suspect that if we do want something like that, it will probably be
>> about combining hardware and software SPI (i.e. we want more SPI busses
>> than the chip can provide in hardware.)
>
> Yes, I guess this is going to happen first. Hopefully not soon, though
> ;-)
>

Yeah, suggesting that something isn't necessary virtually assures that
it will be.

I'll put together a new patch and re-send later today.

regards,
Ben