Wolfgang Denk wd@denx.de wrote:
In message 20080527093432.3026cb15@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