On Fri, Jan 31, 2014 at 12:49 PM, Mark Brown <[email protected]> wrote:
> On Fri, Jan 31, 2014 at 08:49:45AM +0100, Geert Uytterhoeven wrote:
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -829,6 +829,9 @@ void spi_finalize_current_message(struct spi_master
>> *master)
>> queue_kthread_work(&master->kworker, &master->pump_messages);
>> spin_unlock_irqrestore(&master->queue_lock, flags);
>>
>> + if (!mesg)
>> + return NULL;
>> +
>
> Note that this is for transfers, not for messages, and we don't change
> the completion path for the message here so I'm not sure why the message
> would be affected? That said there is definitely an issue here - we
> should probably be adding some sort of error teardown callback to try to
> stop the hardware if we do hit a timeout.
RIght. Sorry, I mixed them up.
One other thing: I haven't tried your patch yet, but I'm afraid the 10 ms
may be too small.
E.g. with PIO-based RSPI I don't get more than 2 Mbps, even though
spi-max-frequency = <30000000>, due to the PIO and interrupt overhead.
Hence a 1 MiB read would take ca. 4s, while your timeout would be 300 ms.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
