[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0910071147020.2762-100000@iolanthe.rowland.org>
Date: Wed, 7 Oct 2009 11:56:18 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
cc: Oliver Neukum <oliver@...kum.org>,
Johan Hovold <jhovold@...il.com>, Greg KH <greg@...ah.com>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 5/5] opticon: Fix resume logic
On Tue, 6 Oct 2009, Alan Cox wrote:
> On Tue, 6 Oct 2009 23:12:17 +0200
> Oliver Neukum <oliver@...kum.org> wrote:
>
> > Am Dienstag, 6. Oktober 2009 17:06:57 schrieb Alan Cox:
> > > Opticon now takes the right mutex to check the port status but the status
> > > check is done wrongly for the modern serial code, so fix it.
> >
> > As Alan Stern noticed, it seems like we have an ab-ba deadlock here
> > between open and resume regarding pm_mutex and port->mutex.
Johan pointed out that I was mistaken in saying the pm_mutex is
acquired during open. It actually is acquired in serial_install() and
serial_cleanup(), which are called without the port mutex. So I guess
we're okay after all.
In the general case, that is. Specific drivers may still run into
trouble. For example, option_open() and sierra_open() do acquire the
pm_mutex.
> Oh well I guess someone with hardware will have to fix that.
>
> Do we actually need a separate pm_mutex anyway ?
In principle we don't, and Rafael Wysocki's new runtime PM framework
doesn't use one. However the current USB runtime PM framework does, so
until we switch over (hopefully in time for 2.6.33) it's important to
watch out for this sort of conflict.
Alan Stern
--
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