From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C8F571 for ; Fri, 29 Jul 2016 03:50:43 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DEBE235 for ; Fri, 29 Jul 2016 03:50:42 +0000 (UTC) Date: Thu, 28 Jul 2016 20:50:55 -0700 From: Greg KH To: Lars-Peter Clausen Message-ID: <20160729035055.GA32225@kroah.com> References: <20160727172636.GM11806@sirena.org.uk> <20160727175829.GG5537@wotan.suse.de> <579A7DFD.60305@metafoo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <579A7DFD.60305@metafoo.de> Cc: ksummit-discuss@lists.linuxfoundation.org, Mauro Carvalho Chehab , "vegard.nossum@gmail.com" , "rafael.j.wysocki" , Valentin Rothberg , Marek Szyprowski Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jul 28, 2016 at 11:49:49PM +0200, Lars-Peter Clausen wrote: > On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote: > > On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote: > >>> to help enable asynchronous probe, however for built-in devices this requires > >>> very specific platform knowledge otherwise using async probe will blow up > >>> your kernel -- if you get it right though, using async probe can help with > >> > >> I'm not sure what specific platform knowledge you're thinking of here? > >> We have coverage for most things in the form of deferred probe (messy > >> though it is). > > > > Deferred probe is a complete a hack and sub-optimal. It's the best hack that people have come up with to solve the problem so far. > I fully agree. In the past though there were a few good attempts of > providing something better than probe deferral, but those were always > quickly shutdown by GregKH for failing to prove that probe deferral > really is insufficient. > > This probably an issue of presentation, but for future attempts it > should be kept in mind that hard numbers on why this is better greatly > improve the chance of it being accepted. If you don't have such numbers, why should I ever accept any changes? You need to show a benefit of code, otherwise you are just pointless churning things for no reason. And also, don't try presenting patches that force every driver or subsystem to be changed for no good reason, that's one reason I have shot down patches in this area as well. good luck! greg k-h