Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2535562pxb; Sat, 23 Oct 2021 01:58:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRtEeeydzX3XFP4UEjpn7fsJd96zhUHcwPaiYnnJeQsIslrtJ+oi475eLSkChh0fJ5BSFQ X-Received: by 2002:a62:e30f:0:b0:47b:d137:bb7b with SMTP id g15-20020a62e30f000000b0047bd137bb7bmr2582228pfh.1.1634979486163; Sat, 23 Oct 2021 01:58:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634979486; cv=none; d=google.com; s=arc-20160816; b=rsYPZfM+Bu7ZP346jRnpBEarSogVxwWxAmQS8LQ3IrECEm4LWipQzgZBMkrcdVxdja HRxpdisOB2feYrj2VWx24OVfyOGoFV1kixb9cmMEgAbgGpExjHFeTR+70EBxN5LH67pI ryItPf39cJamWC+AsB8GsWR6/ylbV9wVooCEcJNzYhGQN7ScWKEUPiL4bjgmM4jsel3w QTVLFDsswf1VmaXHb4nGFiTmmirflW7OsxRbjmTImhbCv6LIGyZ6RsMp5z2D/0QTox6w +dFAVmNZPVnutFwqB2wbQYZrE49VrGWXmlMxqalyTW0+L2r8dKDlcvAXPOcIrYFwtwzo md0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=AoUokewUYmhVvWC7c9/xVgwcEHZrgi/tMfPyESs+nQk=; b=rmH86PMNjtE72otU861FtMv9NxUxpjg3vUfrwdJaVIE2NELFn5gOHIXUkxgcVmvL0o ld2rWrCjM4KAvuiTBuzlJcq4AxRl6PpnqCuvPXtw8MgQrznDvPAv6yKSOzCBg3UdtnQf C/O5y70qSG6YMHLuTIXVkfAaftEdVE9FAPBRy1qm/QC6rrHjFW+DPd2jud3v7N1F+dMa Fdz7L7Mx1KCtxS956koPruY3T+4riokB+xDbIB6QSj2lFsPtl7GYa+52ZcZBHnuhZ4Fs BBORrxS6qYg+id2435kzLEz9q2QRjVZuYif4Sa9C9BwaixYmqmVZZDFaZGlSEM30G63Y k0wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lOgCEGtb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lp3si16964090pjb.117.2021.10.23.01.57.54; Sat, 23 Oct 2021 01:58:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lOgCEGtb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230155AbhJWI7J (ORCPT + 99 others); Sat, 23 Oct 2021 04:59:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:53916 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229666AbhJWI7I (ORCPT ); Sat, 23 Oct 2021 04:59:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9A1EB60FE3; Sat, 23 Oct 2021 08:56:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1634979409; bh=MQ6wVrxyRcZanowXUW3z8SklNft5GH7I+NPAlmFZ89U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lOgCEGtbsXU9ZmPHmlxnRHjXHmdadZCFqhdfjCjqh4b2K//kn9T1Ta5bkvrsjk8Jb NJQXChCKVkfabcQNV5BPInS0yPuMdgsYBDItULN76AoDIYT/WA57772ivr4Pgu4oy5 1cud104Tcdd25BmP5ub1A5ZIQIXvmtr2eXrV8SMo= Date: Sat, 23 Oct 2021 10:56:41 +0200 From: Greg Kroah-Hartman To: Patrick Williams Cc: Zev Weiss , kvm@vger.kernel.org, "Rafael J. Wysocki" , Kirti Wankhede , Jeremy Kerr , Rajat Jain , Frank Rowand , Jianxiong Gao , Dave Jiang , Saravana Kannan , Mauro Carvalho Chehab , openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, Konrad Rzeszutek Wilk , Alex Williamson , Rob Herring , Bhaskar Chowdhury , Thomas Gleixner , Andy Shevchenko , Andrew Jeffery , Cornelia Huck , linux-kernel@vger.kernel.org, Vinod Koul , dmaengine@vger.kernel.org Subject: Re: [PATCH 4/5] driver core: inhibit automatic driver binding on reserved devices Message-ID: References: <20211022020032.26980-1-zev@bewilderbeest.net> <20211022020032.26980-5-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 22, 2021 at 10:18:11AM -0500, Patrick Williams wrote: > Hi Greg, > > On Fri, Oct 22, 2021 at 10:57:21AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Oct 22, 2021 at 01:32:32AM -0700, Zev Weiss wrote: > > > On Thu, Oct 21, 2021 at 11:46:56PM PDT, Greg Kroah-Hartman wrote: > > > > On Thu, Oct 21, 2021 at 07:00:31PM -0700, Zev Weiss wrote: > > > > So we want the kernel to be aware of the device's existence (so that we > > > *can* bind a driver to it when needed), but we don't want it touching the > > > device unless we really ask for it. > > > > > > Does that help clarify the motivation for wanting this functionality? > > > > Sure, then just do this type of thing in the driver itself. Do not have > > any matching "ids" for this hardware it so that the bus will never call > > the probe function for this hardware _until_ a manual write happens to > > the driver's "bind" sysfs file. > > It sounds like you're suggesting a change to one particular driver to satisfy > this one particular case (and maybe I'm just not understanding your suggestion). > For a BMC, this is a pretty regular situation and not just as one-off as Zev's > example. > > Another good example is where a system can have optional riser cards with a > whole tree of devices that might be on that riser card (and there might be > different variants of a riser card that could go in the same slot). Usually > there is an EEPROM of some sort at a well-known address that can be parsed to > identify which kind of riser card it is and then the appropriate sub-devices can > be enumerated. That EEPROM parsing is something that is currently done in > userspace due to the complexity and often vendor-specific nature of it. > > Many of these devices require quite a bit more configuration information than > can be passed along a `bind` call. I believe it has been suggested previously > that this riser-card scenario could also be solved with dynamic loading of DT > snippets, but that support seems simple pretty far from being merged. Then work to get the DT code merged! Do not try to create yet-another-way of doing things here if DT overlays is the correct solution here (and it seems like it is.) thanks, greg k-h