Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1412939pxb; Thu, 21 Oct 2021 23:52:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysrNzLYsE2v/0VV+3KaCKkAUIzOdhl+jx1CA1AZv8IoKiyEBDajP2tvftgIVzXEKletR5h X-Received: by 2002:a17:907:2091:: with SMTP id pv17mr1447254ejb.311.1634885578188; Thu, 21 Oct 2021 23:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634885578; cv=none; d=google.com; s=arc-20160816; b=cYdO0VdFknr48r7QE9vqbi28MNNB2G3KE0BwVxe/V9UijU3DINRyEtkyYynXVjYjt5 0hWtnJV6zlu8UQzT3YwfUlj8QNniPQMXmSF+EAJxyaw331u5gmDNo2apiBKNtpmmiv+5 71EXWErXZNW/ovtNrx7DOT85YV9RfTdKcv6j09nGl8JnBhQkXg8bbDGB87c2v4P4Bune oez64uaJblpYtm4crIT4Bd0GCshJFbaT+87R52teft5NnDbNJLAs5xVXBVF1K1+NghKn M4n9KErU/sDKiVXvxLho4WRwz6umhaopGwDY6GktlX0xwSWOqNdnpn/xwKCzhnUHb6cD 5HSA== 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=V+vzxtxZJrEp1IcSjht3AIfGSlGZfmMeNPDxFo5FFOM=; b=fSATOS++/W/kGx18LVY/WoLA2e4WS1LPV1M1V3jO5LEUsxvyuS2+Kc0oPqo9iND5eZ I3t0CzNKlOG9dpi2wHg0g7WRzOrUoVZjFlYYk5qmpfjukzMand7arC0LXnZhYNtIXz0V 5froNIs0Y2V/njTzeaU1TlBEFn1+kzcyO8LJF2MxVfkO9WitpihXA/pEheYrE5NEqL5U OEBleiJxgQTqKWBp7sHRMfk+cIVYa3nARyKmHH2QStrYQFdgYuOv7I0CXc2O7yBkNyJR i+w5KUz848DFnWUbcocyBTMVvVCJ7DG1GiyNanoNRl+kWOnPITPoFJvRq/fDmcuselGi eKhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=aZWGszIV; 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 i20si10203439ejd.100.2021.10.21.23.52.34; Thu, 21 Oct 2021 23:52:58 -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=aZWGszIV; 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 S232002AbhJVGwa (ORCPT + 99 others); Fri, 22 Oct 2021 02:52:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:59384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232183AbhJVGw3 (ORCPT ); Fri, 22 Oct 2021 02:52:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B720260F50; Fri, 22 Oct 2021 06:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1634885412; bh=c9Eng1ii6V3IjK+Y3GNOcOMLUlsifakRFAI0XTxmwgA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aZWGszIVMVJjGrRpfDp0oFm3sYhGJjcB73qcFkijcxBEOzNOQ5Os8l4MxBbLRjC80 NhcL28v6zWAurvX+nqMUmxFNob/xVgobgQAWYbZpxmmj5VWkaJ8a/K2qmeaIC9ACgv GBnQaS/4YnVIgMp0jJgkqmWz18NoD5d3u/tjyRMk= Date: Fri, 22 Oct 2021 08:50:07 +0200 From: Greg Kroah-Hartman To: Zev Weiss Cc: Frank Rowand , Rob Herring , openbmc@lists.ozlabs.org, Jeremy Kerr , Joel Stanley , Andrew Jeffery , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] driver core, of: support for reserved devices Message-ID: References: <20211022020032.26980-1-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211022020032.26980-1-zev@bewilderbeest.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 21, 2021 at 07:00:27PM -0700, Zev Weiss wrote: > Hello all, > > This series is another incarnation of a couple other patchsets I've > posted recently [0, 1], but again different enough in overall > structure that I'm not sure it's exactly a v2 (or v3). > > As compared to [1], it abandons the writable binary sysfs files and at > Frank's suggestion returns to an approach more akin to [0], though > without any driver-specific (aspeed-smc) changes, which I figure might > as well be done later in a separate series once appropriate > infrastructure is in place. > > The basic idea is to implement support for a status property value > that's documented in the DT spec [2], but thus far not used at all in > the kernel (or anywhere else I'm aware of): "reserved". According to > the spec (section 2.3.4, Table 2.4), this status: > > Indicates that the device is operational, but should not be used. > Typically this is used for devices that are controlled by another > software component, such as platform firmware. > > With these changes, devices marked as reserved are (at least in some > cases, more on this later) instantiated, but will not have drivers > bound to them unless and until userspace explicitly requests it by > writing the device's name to the driver's sysfs 'bind' file. This > enables appropriate handling of hardware arrangements that can arise > in contexts like OpenBMC, where a device may be shared with another > external controller not under the kernel's control (for example, the > flash chip storing the host CPU's firmware, shared by the BMC and the > host CPU and exclusively under the control of the latter by default). > Such a device can be marked as reserved so that the kernel refrains > from touching it until appropriate preparatory steps have been taken > (e.g. BMC userspace coordinating with the host CPU to arbitrate which > processor has control of the firmware flash). > > Patches 1-3 provide some basic plumbing for checking the "reserved" > status of a device, patch 4 is the main driver-core change, and patch > 5 tweaks the OF platform code to not skip reserved devices so that > they can actually be instantiated. Again, the driver core should not care about this, that is up to the bus that wants to read these "reserved" values and do something with them or not (remember the bus is the thing that does the binding, not the driver core). But are you sure you are using the "reserved" field properly? You are wanting to do "something" to the device to later on be able to then have the kernel touch the device, while it seems that the reason for this field is for the kernel to NEVER touch the device at all. What will break if you change this logic? > One shortcoming of this series is that it doesn't automatically apply > universally across all busses and drivers -- patch 5 enables support > for platform devices, but similar changes would be required for > support in other busses (e.g. in of_register_spi_devices(), > of_i2c_register_devices(), etc.) and drivers that instantiate DT > devices. Since at present a "reserved" status is treated as > equivalent to "disabled" and this series preserves that status quo in > those cases I'd hope this wouldn't be considered a deal-breaker, but > a thing to be aware of at least. > > Greg: I know on [1] you had commented nack-ing the addition of boolean > function parameters; patch 4 adds a flags mask instead in an analogous > situation. I'm not certain how much of an improvement you'd consider > that (hopefully at least slightly better, in that the arguments passed > at the call site are more self-explanatory); if that's still > unsatisfactory I'd welcome any suggested alternatives. Flags are a bit better, yes, but still I do not think this is the right way to go here, see my comments on the patches... thanks, greg k-h