From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755893AbbFCOHd (ORCPT ); Wed, 3 Jun 2015 10:07:33 -0400 Received: from mail.windriver.com ([147.11.1.11]:64292 "EHLO mail.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754133AbbFCOH0 (ORCPT ); Wed, 3 Jun 2015 10:07:26 -0400 Message-ID: <556F0A17.2050306@windriver.com> Date: Wed, 3 Jun 2015 10:07:19 -0400 From: Paul Gortmaker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linus Walleij CC: "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman Subject: Re: [PATCH 1/7] platform_device: better support builtin boilerplate avoidance References: <1431287385-1526-1-git-send-email-paul.gortmaker@windriver.com> <1431287385-1526-2-git-send-email-paul.gortmaker@windriver.com> <20150528005022.GA23774@windriver.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [128.224.56.57] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15-06-02 05:19 AM, Linus Walleij wrote: > On Thu, May 28, 2015 at 2:50 AM, Paul Gortmaker > wrote: >> [Re: [PATCH 1/7] platform_device: better support builtin boilerplate avoidance] On 12/05/2015 (Tue 13:46) Linus Walleij wrote: >> >>> This does not inhibit probe() and remove() to be >>> triggered from sysfs does it? >>> >>> What is needed on builtin drivers is to set >>> .suppress_bind_attrs = true on the struct device_driver >>> so that we inhibit the creation of sysfs files to probe >>> and remove the driver by operator intervention. >> >> Is this needed? I think we will break existing use cases if we do this. >> >> For example, I have IGB as built-in, but I can still unbind one of the >> four devices and make it available for PCI pass through to KVM with: >> >> echo "0000:0a:00.1" > /sys/bus/pci/drivers/igb/unbind >> echo "0000:0a:00.1" > /sys/bus/pci/drivers/pci-stub/bind > > Aha PCI device which noone else is dependent on, I guess > it's true. > > I think we have a problem as to what "builtin" really means. Well, people have had trouble with what "is" means before, so I guess it is possible. However, I think here it is pretty clear that builtin means a Kconfig which is "y" and where "m" is not a possible selection. > For example if this is a builtin regulator, clock, GPIO, DMA etc > driver, we want to suppress the binding/unbinding from userspace > too, since these drivers provide resources to others and > if you unbind them, nasty things happen. Unbinding/rebinding > is fine as long as noone else depend on you. However for > a large number of builtins, that is the case :P So, to summarize: 1) Currently drivers can unbind that really should not do so. 2) This is not a new issue, nor is it introduced by this series. 3) We can't set policy based on built in vs modular; the only sane thing appears to be to let the driver decide itself. Paul. -- > > Yours, > Linus Walleij >