[Top] [All Lists]

Re: [PATCH V5 16/17] SPI: MIPS: lantiq: add FALCON spi driver

To: Grant Likely <>
Subject: Re: [PATCH V5 16/17] SPI: MIPS: lantiq: add FALCON spi driver
From: John Crispin <>
Date: Sat, 26 May 2012 15:47:24 +0200
Cc: Ralf Baechle <>,,, Thomas Langer <>
In-reply-to: <20120525233845.BD93C3E0BD2@localhost>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <20120525233845.BD93C3E0BD2@localhost>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Icedove/3.1.16
> 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 ...

<Prev in Thread] Current Thread [Next in Thread>