On 04/04/2018 10:08 AM, Maxime Ripard wrote:
On Tue, Apr 03, 2018 at 07:24:11PM +0300, Sergey Suloev wrote:
On 04/03/2018 07:18 PM, Mark Brown wrote:
On Tue, Apr 03, 2018 at 07:00:55PM +0300, Sergey Suloev wrote:
On 04/03/2018 06:52 PM, Mark Brown wrote:
On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote:
As long as sun4i/sun6i SPI drivers have overriden the default
"wait for completion" procedure then we need to properly
handle -ETIMEDOUT error from transfer_one().
Why is this connected to those drivers specifically?
These 2 drivers have their own "waiting" code and not using the code from
SPI core.
Does this not apply to any other driver - why is this something we only
have to do when these drivers do it? That's what's setting off alarm
bells.
sun4i/sun6i drivers have let's say "smart" waiting while SPI core uses a
fixed interval to wait.
I can't say for every SPI driver in kernel, that's outside of my area of
expertise.
I'm not sure what's specific about the sun4i / sun6i case here. Your
patch doesn't have anything to do with the delay before the timeout,
but the fact that we return -ETIMEDOUT in the first place.
And I'm pretty sure that papering over an error returned by a driver
is not the right thing to do.
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
do you mean the changes in spi.c are not required at all ?
My point was to eat ETIMEDOUT error from transfer_one() as it is just a
mark and
shouldn't be handled as a normal error.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
