On Mon, Feb 14, 2011 at 4:16 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Sun, 2011-02-13 at 09:56 -0800, Nathaniel J. Smith wrote:
>> This patch should cause no behavioral change whatsoever.
>
> Right -- but it makes the TX path quite a bit more expensive on some
> architectures. Why is this necessary? There should be locking in most
> places already, and where not it should be easy to move this under the
> existing lock.
Yes, I suspect we could use the priv->lock for this purpose (at the
expense of adding a lock/unlock on the TX notification path), but I'd
like some confirmation from someone more familiar with the code before
trying. high_mark is read from all over the place, and was previously
read-only, so it really needs someone who understands this driver's
locking "big picture" to check correctness.
In particular, is it safe to acquire priv->lock from inside
{iwl3945,iwlagn}_tx_queue_reclaim? Or can they be called on a path
where the that lock is already held?
-- Nathaniel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
