On Sat, 26 May 2012 15:47:24 +0200, John Crispin <blogic@xxxxxxxxxxx> wrote:
>
> > 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 ...
Hahah. I receive a *lot* of email. I can't remember what I reviewed
yesterday, let alone last week. If I ack something, then add my ack
when you repost. Otherwise I don't have any clues as to what I've
said in the past.
Also, I reserve the right to review all new versions of patches; that
doesn't invalidate the ack, but Ralf can decide whether to pick it up
and ask for follow-up changes, or to ask for another respin.
g.
