[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UpBG8gmPjWDF0M9EMSvs4pg7icocMXJ1r3Lmi8frZsrg@mail.gmail.com>
Date: Mon, 25 Jun 2012 10:07:35 -0700
From: Doug Anderson <dianders@...omium.org>
To: Olof Johansson <olof@...om.net>
Cc: Bryan Freed <bfreed@...omium.org>,
spi-devel-general@...ts.sourceforge.net, grant.likely@...retlab.ca,
linux-kernel@...r.kernel.org, LinusW <linus.walleij@...aro.org>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH] spi: Unlock a spinlock before calling into the controller driver.
Olof,
On Sun, Jun 24, 2012 at 4:54 PM, Olof Johansson <olof@...om.net> 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 at that time.
I spent a bunch of time staring at the code and I'm pretty sure that
there's no race and that the code is safe (if not super obvious).
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 called because the only caller to
prepare/unprepare is spi_pump_messages().
I can't comment on whether it's better to do something like add a
workqueue (which might be more obvious / less fragile) or just to add
a comment. I will let others comment on that. :)
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists