> What exactly does this mean? How does it not support any other type
> of SPI peripheral? SPI is a really simple protocol, so what is it
> about this hardware that prevents it being used with other SPI
> hardware?
>
> I see a big state machine that appears to interpret the messages and
> pretend to be an SPI slave instead of telling linux about the real
> device. /me wonders if it should this instead be a block device
> driver?
>
Thomas will need to comment on this part
>> +static int falcon_sflash_prepare_xfer(struct spi_master *master)
>> +{
>> + return 0;
>> +}
>> +
>> +static int falcon_sflash_unprepare_xfer(struct spi_master *master)
>> +{
>> + return 0;
>> +}
> Don't use empty hooks. Just leave them uninitialized. The core will
> do the right thing.
>
I was under the impression that the need for these 2 callbacks was
removed in 3.5. As this patch flows via MIPS there would be a merge
order problem making the kernel non bisectable
I am a bit confused. You keep ack'ing this driver and then commenting on
it a few weeks later.... obsoleting the ACK ...
