[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201203060910.52207.arnd@arndb.de>
Date: Tue, 6 Mar 2012 09:10:51 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: linux-kernel@...r.kernel.org, Tony Lindgren <tony@...mide.com>,
"Greg Kroah-Hartman" <greg@...ah.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Dilan Lee <dilee@...dia.com>,
Manjunath GKondaiah <manjunath.gkondaiah@...aro.org>,
Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism
On Monday 05 March 2012, Grant Likely wrote:
> >
> > Also, What protects the device from going away between being put on the list
> > and taken off of it? Don't you have to do the device_get during
> > driver_deferred_probe_add()?
>
> The deferred_probe_mutex. Nothing can be removed from the deferred
> list without holding the deferred_probe_mutex, and no device can be
> freed before it is taken off the deferred list. If the device is in
> the process of being removed, then get_device() occurs before dropping
> the mutex to protect against freeing, and bus_probe_device() won't
> attach a driver to a device getting removed.
Ok, got it now. So there were actually three bugs that I found that
turned out to be correct in the end. This also means that if you
want to change to making deferred_probe_active_list local
to the work function and not locked, you actually will need to
get the reference count on the device as soon as you put it on
the pending list. Since that would be a major design change with
little benefit, I agree that you should not change it from the tested
version for now.
Arnd
--
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