From: Bryan Freed
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
On Sat, Jun 23, 2012 at 7:53 AM, Bryan Freed 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 before making the
On Tue, Jun 26, 2012 at 1:07 AM, Doug Anderson 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 when prepare is cal
Olof,
On Sun, Jun 24, 2012 at 4:54 PM, Olof Johansson wrote:
> I'm not sure this is safe to do. The lock is dropped for the prepare
> side, but in that case we can be sure that the above code can't come
> in and unprepare at the same time since there is per definition a
> request on the queue a
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 wrote:
> spi_pump_messages() calls into a controller driver with
> unprepare_transfer_hardware() which is documented as "This may sleep".
> As in the prepare_t
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
