From: Zev Weiss <email@example.com> To: firstname.lastname@example.org Cc: email@example.com, "Vignesh Raghavendra" <firstname.lastname@example.org>, "Zev Weiss" <email@example.com>, "Tudor Ambarus" <firstname.lastname@example.org>, "Andrew Jeffery" <email@example.com>, "Greg Kroah-Hartman" <firstname.lastname@example.org>, email@example.com, "Richard Weinberger" <firstname.lastname@example.org>, "Michael Walle" <email@example.com>, "Rob Herring" <firstname.lastname@example.org>, email@example.com, "Cédric Le Goater" <firstname.lastname@example.org>, "Miquel Raynal" <email@example.com>, "Jeremy Kerr" <firstname.lastname@example.org>, email@example.com, "Frank Rowand" <firstname.lastname@example.org>, "Pratyush Yadav" <email@example.com>, firstname.lastname@example.org Subject: [PATCH 0/6] Dynamic aspeed-smc flash chips via "reserved" DT status Date: Wed, 29 Sep 2021 04:54:02 -0700 [thread overview] Message-ID: <email@example.com> (raw) Hello, This patch series aims to improve a scenario that arises in OpenBMC and which isn't handled very well at the moment. Certain devices, the example at hand being the flash chip used to store the host's firmware (e.g. the BIOS), may be shared between the BMC and the host system but only available to one or the other at any given time. The device may thus be effectively off-limits to the BMC when it boots, and only usable after userspace performs the necessary steps to coordinate appropriately with the host (tracking its power state, twiddling GPIOs, sending IPMI commands, etc.). Neither the "okay" nor the "disabled" device-tree status values works nicely for the flash device this case -- an "okay" device gets probed automatically as soon as the device and a driver for it are available, and a "disabled" one gets forgotten about entirely, whereas we want the BMC's kernel to be aware of the existence of the device, but not try to actually do anything with it (i.e. probe it) until explicitly requested to do so by userspace. However, while there's no support for it currently in the kernel tree, the device-tree spec  also lists "reserved" as a possible status value, and its description seems like a fairly reasonable fit for this situation: 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. These patches start making use of this status value in the aspeed-smc driver. The first patch adds a companion routine to of_device_is_available() that checks for a "reserved" status instead of "okay". The second patch is a small MTD adjustment to allow an unregistered device to be cleanly re-registered. Patches 3 through 5 modify the aspeed-smc driver to allow individual chips to be attached and detached at runtime, and to avoid automatically attaching any marked as reserved. Finally, patch 6 employs the newly-supported status in adding support for the BIOS flash device to the ASRock Rack e3c246d4i BMC. Thanks, Zev  https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf Zev Weiss (6): of: base: Add function to check for status = "reserved" mtd: core: clear out unregistered devices a bit more mtd: spi-nor: aspeed: Refactor registration/unregistration mtd: spi-nor: aspeed: Allow attaching & detaching chips at runtime mtd: spi-nor: aspeed: Don't automatically attach reserved chips ARM: dts: aspeed: Add e3c246d4i BIOS flash device .../ABI/stable/sysfs-driver-aspeed-smc | 17 ++ .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 16 ++ drivers/mtd/mtdcore.c | 7 +- drivers/mtd/spi-nor/controllers/aspeed-smc.c | 177 +++++++++++++++--- drivers/of/base.c | 53 +++++- include/linux/of.h | 6 + 6 files changed, 238 insertions(+), 38 deletions(-) create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-smc -- 2.33.0
next reply other threads:[~2021-09-29 11:56 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-29 11:54 Zev Weiss [this message] 2021-09-29 11:54 ` [PATCH 1/6] of: base: Add function to check for status = "reserved" Zev Weiss 2021-09-29 15:49 ` Rob Herring 2021-09-29 11:54 ` [PATCH 2/6] mtd: core: clear out unregistered devices a bit more Zev Weiss 2021-09-29 11:54 ` [PATCH 3/6] mtd: spi-nor: aspeed: Refactor registration/unregistration Zev Weiss 2021-10-06 0:03 ` Dhananjay Phadke 2021-09-29 11:54 ` [PATCH 4/6] mtd: spi-nor: aspeed: Allow attaching & detaching chips at runtime Zev Weiss 2021-09-29 11:54 ` [PATCH 5/6] mtd: spi-nor: aspeed: Don't automatically attach reserved chips Zev Weiss 2021-09-29 11:54 ` [PATCH 6/6] ARM: dts: aspeed: Add e3c246d4i BIOS flash device Zev Weiss 2021-09-29 16:08 ` [PATCH 0/6] Dynamic aspeed-smc flash chips via "reserved" DT status Rob Herring 2021-09-29 22:00 ` Zev Weiss
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/6] Dynamic aspeed-smc flash chips via "reserved" DT status' \ /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: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).