From: Bryan Freed bfr...@chromium.org
spi_pump_messages() calls into a controller driver with
unprepare_transfer_hardware() which is documented as This may sleep.
As in the prepare_transfer_hardware() call below, we should release the
queue_lock spinlock before making the call.
Rework the logic a
On Tue, Jun 26, 2012 at 1:07 AM, Doug Anderson diand...@chromium.org wrote:
Specifically there should be only one instance of spi_pump_messages()
running at a time per master. That's because it's a kthread work
function. ...so we can't possibly get a prepare in the middle of the
unprepare
On Sat, Jun 23, 2012 at 7:53 AM, Bryan Freed bfr...@chromium.org wrote:
spi_pump_messages() calls into a controller driver with
unprepare_transfer_hardware() which is documented as This may sleep.
As in the prepare_transfer_hardware() call below, we should release the
queue_lock spinlock
Hi,
(Adding Linus Walleij and Mark Brown since they were the ones doing
the queue changes).
On Fri, Jun 22, 2012 at 4:53 PM, Bryan Freed bfr...@chromium.org wrote:
spi_pump_messages() calls into a controller driver with
unprepare_transfer_hardware() which is documented as This may sleep.
As
spi_pump_messages() calls into a controller driver with
unprepare_transfer_hardware() which is documented as This may sleep.
As in the prepare_transfer_hardware() call below, we should release the
queue_lock spinlock before making the call.
Rework the logic a bit to hold queue_lock to protect the
