From: Zev Weiss <zev@bewilderbeest.net> To: Frank Rowand <frowand.list@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org> Cc: openbmc@lists.ozlabs.org, Jeremy Kerr <jk@codeconstruct.com.au>, Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Zev Weiss <zev@bewilderbeest.net> Subject: [PATCH 0/5] driver core, of: support for reserved devices Date: Thu, 21 Oct 2021 19:00:27 -0700 [thread overview] Message-ID: <20211022020032.26980-1-zev@bewilderbeest.net> (raw) 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. 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. Thanks, Zev [0] https://lore.kernel.org/openbmc/20210929115409.21254-1-zev@bewilderbeest.net/ [1] https://lore.kernel.org/openbmc/20211007000954.30621-1-zev@bewilderbeest.net/ [2] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf Zev Weiss (5): of: base: add function to check for status = "reserved" device property: add fwnode_device_is_reserved() of: property: add support for fwnode_device_is_reserved() driver core: inhibit automatic driver binding on reserved devices of: platform: instantiate reserved devices drivers/base/bus.c | 2 +- drivers/base/dd.c | 13 ++++++---- drivers/base/property.c | 16 +++++++++++++ drivers/dma/idxd/compat.c | 3 +-- drivers/of/base.c | 56 ++++++++++++++++++++++++++++++++++++------- drivers/of/platform.c | 2 +- drivers/of/property.c | 6 +++++ drivers/vfio/mdev/mdev_core.c | 2 +- include/linux/device.h | 14 ++++++++++- include/linux/fwnode.h | 2 ++ include/linux/of.h | 6 +++++ include/linux/property.h | 1 + 12 files changed, 104 insertions(+), 19 deletions(-) -- 2.33.1
WARNING: multiple messages have this Message-ID (diff)
From: Zev Weiss <zev@bewilderbeest.net> To: Frank Rowand <frowand.list@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org, Zev Weiss <zev@bewilderbeest.net>, Andrew Jeffery <andrew@aj.id.au>, openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jeremy Kerr <jk@codeconstruct.com.au> Subject: [PATCH 0/5] driver core, of: support for reserved devices Date: Thu, 21 Oct 2021 19:00:27 -0700 [thread overview] Message-ID: <20211022020032.26980-1-zev@bewilderbeest.net> (raw) 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. 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. Thanks, Zev [0] https://lore.kernel.org/openbmc/20210929115409.21254-1-zev@bewilderbeest.net/ [1] https://lore.kernel.org/openbmc/20211007000954.30621-1-zev@bewilderbeest.net/ [2] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf Zev Weiss (5): of: base: add function to check for status = "reserved" device property: add fwnode_device_is_reserved() of: property: add support for fwnode_device_is_reserved() driver core: inhibit automatic driver binding on reserved devices of: platform: instantiate reserved devices drivers/base/bus.c | 2 +- drivers/base/dd.c | 13 ++++++---- drivers/base/property.c | 16 +++++++++++++ drivers/dma/idxd/compat.c | 3 +-- drivers/of/base.c | 56 ++++++++++++++++++++++++++++++++++++------- drivers/of/platform.c | 2 +- drivers/of/property.c | 6 +++++ drivers/vfio/mdev/mdev_core.c | 2 +- include/linux/device.h | 14 ++++++++++- include/linux/fwnode.h | 2 ++ include/linux/of.h | 6 +++++ include/linux/property.h | 1 + 12 files changed, 104 insertions(+), 19 deletions(-) -- 2.33.1
next reply other threads:[~2021-10-22 2:00 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-22 2:00 Zev Weiss [this message] 2021-10-22 2:00 ` [PATCH 0/5] driver core, of: support for reserved devices Zev Weiss 2021-10-22 2:00 ` [PATCH 1/5] of: base: add function to check for status = "reserved" Zev Weiss 2021-10-22 2:00 ` Zev Weiss 2021-10-22 6:43 ` Greg Kroah-Hartman 2021-10-22 6:43 ` Greg Kroah-Hartman 2021-10-22 7:38 ` Zev Weiss 2021-10-22 7:38 ` Zev Weiss 2021-10-22 7:45 ` Greg Kroah-Hartman 2021-10-22 7:45 ` Greg Kroah-Hartman 2021-10-22 2:00 ` [PATCH 2/5] device property: add fwnode_device_is_reserved() Zev Weiss 2021-10-22 2:00 ` Zev Weiss 2021-10-22 2:00 ` [PATCH 3/5] of: property: add support for fwnode_device_is_reserved() Zev Weiss 2021-10-22 2:00 ` Zev Weiss 2021-10-22 2:00 ` [PATCH 4/5] driver core: inhibit automatic driver binding on reserved devices Zev Weiss 2021-10-22 2:00 ` Zev Weiss 2021-10-22 6:46 ` Greg Kroah-Hartman 2021-10-22 6:46 ` Greg Kroah-Hartman 2021-10-22 8:32 ` Zev Weiss 2021-10-22 8:32 ` Zev Weiss 2021-10-22 8:57 ` Greg Kroah-Hartman 2021-10-22 8:57 ` Greg Kroah-Hartman 2021-10-22 15:18 ` Patrick Williams 2021-10-22 15:18 ` Patrick Williams 2021-10-23 8:56 ` Greg Kroah-Hartman 2021-10-23 8:56 ` Greg Kroah-Hartman 2021-10-25 5:38 ` Frank Rowand 2021-10-25 5:38 ` Frank Rowand 2021-10-25 6:15 ` Greg Kroah-Hartman 2021-10-25 6:15 ` Greg Kroah-Hartman 2021-10-25 11:44 ` Patrick Williams 2021-10-25 11:44 ` Patrick Williams 2021-10-25 12:58 ` Andy Shevchenko 2021-10-25 12:58 ` Andy Shevchenko 2021-10-25 13:20 ` Patrick Williams 2021-10-25 13:20 ` Patrick Williams 2021-10-25 13:34 ` Greg Kroah-Hartman 2021-10-25 13:34 ` Greg Kroah-Hartman 2021-10-25 14:02 ` Patrick Williams 2021-10-25 14:02 ` Patrick Williams 2021-10-25 14:09 ` Greg Kroah-Hartman 2021-10-25 14:09 ` Greg Kroah-Hartman 2021-10-25 15:54 ` Patrick Williams 2021-10-25 15:54 ` Patrick Williams 2021-10-25 18:36 ` Greg Kroah-Hartman 2021-10-25 18:36 ` Greg Kroah-Hartman 2021-10-22 16:27 ` Zev Weiss 2021-10-22 16:27 ` Zev Weiss 2021-10-23 8:55 ` Greg Kroah-Hartman 2021-10-23 8:55 ` Greg Kroah-Hartman 2021-10-22 2:00 ` [PATCH 5/5] of: platform: instantiate " Zev Weiss 2021-10-22 2:00 ` Zev Weiss 2021-10-22 2:58 ` [PATCH 0/5] driver core, of: support for " Rob Herring 2021-10-22 2:58 ` Rob Herring 2021-10-22 3:13 ` Zev Weiss 2021-10-22 3:13 ` Zev Weiss 2021-10-22 6:50 ` Greg Kroah-Hartman 2021-10-22 6:50 ` Greg Kroah-Hartman 2021-10-22 6:50 ` Greg Kroah-Hartman 2021-10-22 6:50 ` Greg Kroah-Hartman 2021-10-22 9:00 ` Zev Weiss 2021-10-22 9:00 ` Zev Weiss 2021-10-22 9:22 ` Greg Kroah-Hartman 2021-10-22 9:22 ` Greg Kroah-Hartman 2021-10-25 5:53 ` Frank Rowand 2021-10-25 5:53 ` Frank Rowand 2021-10-25 13:57 ` Frank Rowand 2021-10-25 13:57 ` Frank Rowand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211022020032.26980-1-zev@bewilderbeest.net \ --to=zev@bewilderbeest.net \ --cc=andrew@aj.id.au \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=jk@codeconstruct.com.au \ --cc=joel@jms.id.au \ --cc=linux-kernel@vger.kernel.org \ --cc=openbmc@lists.ozlabs.org \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.