From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0D3D3E0C45 for ; Tue, 24 Mar 2026 15:21:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774365701; cv=none; b=WdaybSvJrZqMDlpJLuL/qlXNUSiwpurLrT4aNIP5SSwDA27nv5AUEARPpXBTckoMeNG7LcsrW+2PXMIa/kMAgw8JQX4X+9NDpbffVJ6jY0RTw64Jr5sImOpgala9pTmbeWjXsCU8qmopXU2pvO+WY2q8N4kTMPBkRNocn9mtmZ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774365701; c=relaxed/simple; bh=NJo5NdzOjtwBWX7+M/YjO+ycHqysL7+cmpjOt2K5IaQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=svpN75OrooLLDJVHtrYqaDG1b79JW+1qUFSlKY96DeSFLnZzWr4oqeqDCuQNwscwAppJn/V2NUrXARuf4OC/qMaxxD6AXwk3ONCfCuo0dHBH5T4k1UD/BgxGk5qynu1znP3Z4TAg7dQmpYcWr2PXV5QwKSRDKyQ5NBrd18jmJys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=JV3Aj0v+; arc=none smtp.client-ip=209.85.222.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="JV3Aj0v+" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-8cfd122d78fso623084185a.3 for ; Tue, 24 Mar 2026 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1774365699; x=1774970499; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tiLKmr/C5OTHsK7h85BV4WJ+HRj+xEBrHGkLJfB0mtU=; b=JV3Aj0v+Z46SyNtzD3i8WnoW8IVMMjJ+bWg/7mBLKr22fMpeV3H9SRZBml8Tdqags5 LswoX19VCleisShCsdoXaHop+rRiVHzL5UK1KyG80/WMOP+2DwRB85Acw2BJML05Qc7F xSHtjd36bx26pZoDTOqyK52YA0Tmw+D8KdgtZYQygzTbGKalFoxLdXzeGK9CtYedYmd8 ArKxZf88U++cIeymF0QvvwM4XWdJP7eyVIiz59RyQGubdPKFVt5ptJ5Jih+beK+sLqU7 iD+MAJ5J3i6T9j6yVYc2ydiHMXx0ljuOFtH7RBzWS/X61ekdd2B6+e5/RLxTWS2EVqmE QgBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774365699; x=1774970499; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tiLKmr/C5OTHsK7h85BV4WJ+HRj+xEBrHGkLJfB0mtU=; b=QfJ47+Hhcvy7tZ7LJK45sT+YR2mJewxZmmbkZBJDsaLNNwoyKd7bDxsqsVBzLLPZb0 P6cXeLXkCgarYvD8Qr1CLVEIi5wfYejIk9DaxowTlfoE+P+nji5ozw1g/J8axV/j0dyL 4VpuSzEi26WnAE3rbThLQecjH5OHzIL1zPXLM/YXghgIKGuo7AMXXRGA3v4Da7qhWfuh EA0nvWiBa2QfY3LnHmKmWaYyLgsp7vtXAPZ3KLaM8qci1hhw+ZL78QPTZBfvjZ5A4EVE i63L83DRta2CqIyaRhz2tp5UQJrhljmb7UbTsFGLeUp412L6idy8IUwlgw60Lv/BWyVB ZQbA== X-Forwarded-Encrypted: i=1; AJvYcCWqy19EiZmx99XKfFSSukfGF8kTkbDDuRhXos5RdusPlJSUU3RuihfknagcuESchnyU9xAskSXHTPKo8Dg=@vger.kernel.org X-Gm-Message-State: AOJu0YwZqY4bb9hBvZkHIAhBGfGFQHEmid+X0unGfwHQ0z7zspllvwQL 4JfBQ+YE+l4kvRGgFAFOc/LbYJe/mItgxMJ01v9TlUAzbr1xZsUm6sd3w+ph28vJkg== X-Gm-Gg: ATEYQzwpmZY9bZepczI+s2j8FwiFeiAr057T1aSWuzaTzSlO8RcBfn79XRn3T3ex6vq 4JrG6a7w94i8wx8R17pfweUflQ8cCsXhA1Muf5c+BMK0MghmtosvFSL6FHv8T9u440HBBCFC+te DAMhXbEdXQ/a3LC2nRl0zcXEpfpqQJaU2C8dzWayN9rvsAJB+6fzF9jHcU7WkMwaWHP+Lcm+GB+ +cu7rnO3wFvTSm7eC8roRWyC7VVh/lUjdl7PpSi3CSAzUR65BCXjLmY+EUgFFwfGm1dBFk909zs AraahwdP1HreaXlyWM0KM1svrt5copzYl9sE8Z47r3cgXpdMaGEyeJu9gpQUEPt7MMZw6xRHpuu JARaFxain4uS3zgIPWXq6mpkfY4J8+sS6h1di7c8Q5wT3uhuy+A4tXw1kVpI1vkpXsNaoqacBmu EIUu9aw+4DY2ZhOIutqN7n/WpJ X-Received: by 2002:a05:620a:408b:b0:8cf:de1c:ede4 with SMTP id af79cd13be357-8cfde1cf987mr1729724985a.26.1774365697099; Tue, 24 Mar 2026 08:21:37 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:d01:d210::9c76]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cfc90b4a7fsm1015857885a.32.2026.03.24.08.21.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 08:21:36 -0700 (PDT) Date: Tue, 24 Mar 2026 11:21:33 -0400 From: Alan Stern To: Doug Anderson Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , Saravana Kannan , stable@vger.kernel.org, driver-core@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] driver core: Don't link the device to the bus until we're ready to probe Message-ID: References: <20260320200656.RFC.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid> <2026032152-getting-carmaker-29d5@gregkh> <2026032114-unlocked-unmoving-091b@gregkh> <6ff1444b-f83e-47f6-ab0d-6745738523ba@rowland.harvard.edu> <6511a5b9-ac67-49a1-8336-3d2afaaab593@rowland.harvard.edu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 23, 2026 at 03:24:52PM -0700, Doug Anderson wrote: > > You know, I wrote this but I'm not so sure that it's accurate. We've > > gone many years with no big changes to this code; most likely it doesn't > > need alterations now. > > That's fair, but I'm really just worried that the Android parallel > module loading code, which is only ~1 year old (and needs to be opted > in for each device) is stressing things in a way that nobody else is. > In most distros, I think modules are loaded "on-demand". A device gets > added first, and then we figure out which module has the driver that's > needed and load the module. Nice and sequential. Android seems to have > a different approach. As far as I understand it just has a list of > modules to load and slams through loading all of them even as devices > are still being added. > > I don't think that what Android is doing is technically "wrong", but > it's certainly odd compared to all other distros. > > Unless we say that what Android is doing is wrong (and decide what to > do about it), it seems like we need to make sure it's robust. Loading a bunch of modules as fast as possible should not be wrong. The kernel certainly ought to be able to handle it. > > Nothing wrong with those names. But instead of making these fairly > > intrusive changes it might be better just to move the firmware stuff to > > a different place in the code (you mentioned this possibility in your > > first email). It would be a smaller change, that's for sure. > > I'll do that if that's what everyone wants, but the more I think about > it the more worried I am that we'll end up with a hidden / harder to > debug problem where some driver gets unhappy when its probe is called > before dpm_sysfs_add(), device_pm_add(), device_create_file(), > device_create_sys_dev_entry(), BUS_NOTIFY_ADD_DEVICE, ... It's hard to know for all of them. However, it seems pretty clear that device_pm_add() should come before probing, since a probe routine will generally want to affect the device's runtime PM state. > > There should not be any difference between probing caused by the device > > being added to the bus, vs. caused by a new driver being registered, vs. > > caused by anything else (such as sysfs). None of these should be > > allowed until all of them can be handled properly. > > Right. ...and I think that's what my proposed "ready_to_probe" does. > It really does seem like quite a safe change. It _just_ prevents the > driver load path from initiating a probe too early. Any such consideration should apply to all the probe paths, not just driver loading. (Also, if it's too early to probe the device, perhaps the return code should be -EAGAIN instead of 0.) I'm not at all sure whether the constraints we've got will need to force some events to happen after adding the device to the bus list and before allowing probing to start. > > And linking the device into the bus's list of devices should be the > > event that makes probing possible. > > Sure, but moving the linking into the bus's list of devices all the > way to the end is definitely a bigger change. If nothing else, > "bus_for_each_dev()" starts to be able to find the device once it's > linked into the list. If any of the ~50 drivers who register for > BUS_NOTIFY_ADD_DEVICE are relying on the device to show up in > "bus_for_each_dev()", it would be bad... I don't know the answer to this. That is, I don't know if there are any notification handlers depending on the device showing up in the bus's list. The safest thing to do is issue the notification after adding the device to the list -- which may mean after probing has potentially started. Is there any reason why that would be a problem? I'm not aware of any. The order constraints should be commented explicitly in device_add(), not just implicitly implied by the code. Otherwise people won't know what changes are allowed and what changes are forbidden. Alan Stern