From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756541AbZEJWTZ (ORCPT ); Sun, 10 May 2009 18:19:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753305AbZEJWTP (ORCPT ); Sun, 10 May 2009 18:19:15 -0400 Received: from gate.crashing.org ([63.228.1.57]:57923 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437AbZEJWTO (ORCPT ); Sun, 10 May 2009 18:19:14 -0400 Subject: Re: Device core removal ordering brokenness From: Benjamin Herrenschmidt To: Alan Stern Cc: Greg KH , Linux Kernel list , David Woodhouse , Andrew Morton In-Reply-To: References: Content-Type: text/plain Date: Mon, 11 May 2009 08:17:04 +1000 Message-Id: <1241993824.19955.14.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2009-05-10 at 10:58 -0400, Alan Stern wrote: > Before the patch, the ordering was like this: > > device_add: ADD dpm_sysfs_add() ->probe > device_del: dpm_sysfs_remove() ->remove DEL Right. > Now the ordering is like this: > > device_add: dpm_sysfs_add() ADD ->probe > device_del: DEL dpm_sysfs_remove() ->remove > > Okay, yes, it's not symmetrical. But the point of the patch was to put > the DEL before the dpm_sysfs_remove(), and in any case the code wasn't > symmetrical even before the patch. How so ? It does definitely look symetrical above :-) That's not a big deal per-se though, it's just that I want to be able to tear down data structures in DEL that may be indirectly used by the driver (DMA mapping related or even MMIO related internal arch stuff). > I gather that you'd prefer to see > > device_del: ->remove DEL dpm_sysfs_remove() I don't actually care that much about where drm_sysfs_remove() is vs. DEL, but you seem to want to adjust the sysfs files in ADD and DEL, so that would make sense. > Offhand I can't think of any reason not to do this. Maybe someone else > can; this code has a lot of undocumented constraints. (Hmm, what > happens if a system suspend occurs after the device has been > unregistered from its bus but before it has been taken off the dpm > list? It's probably okay but worth checking...) > > If you'd like to submit a patch moving the "if (dev->bus)...", > device_pm_remove(), and dpm_sysfs_remove() stuff after the call to > bus_remove_device(), go ahead. I first want to "probe" you guys in case there's some nasty skeleton waiting around the corner, but yeah I'll probably do that. One other option is to split DEL in two. Ben