openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Zev Weiss <zev@bewilderbeest.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
	"moderated list:ARM/ASPEED MACHINE SUPPORT"
	<linux-aspeed@lists.ozlabs.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Jeremy Kerr" <jk@codeconstruct.com.au>,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"OpenBMC Maillist" <openbmc@lists.ozlabs.org>,
	"Andrey Konovalov" <andreyknvl@gmail.com>,
	"Alexey Dobriyan" <adobriyan@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
	"Daniel Axtens" <dja@axtens.net>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Heiner Kallweit" <hkallweit1@gmail.com>
Subject: Re: [PATCH 0/9] Dynamic DT device nodes
Date: Thu, 7 Oct 2021 02:05:41 -0700	[thread overview]
Message-ID: <YV64ZbcsHvBObH2j@hatter.bewilderbeest.net> (raw)
In-Reply-To: <CAHp75VdYBB_FaMr-uKswdvDBdobTYZkiE6ncoALuG+YYVoMwyw@mail.gmail.com>

On Thu, Oct 07, 2021 at 12:04:41AM PDT, Andy Shevchenko wrote:
>On Thu, Oct 7, 2021 at 3:10 AM Zev Weiss <zev@bewilderbeest.net> wrote:
>> This patch series is in some ways kind of a v2 for the "Dynamic
>> aspeed-smc flash chips via 'reserved' DT status" series I posted
>> previously [0], but takes a fairly different approach suggested by Rob
>> Herring [1] and doesn't actually touch the aspeed-smc driver or
>> anything in the MTD subsystem, so I haven't marked it as such.
>>
>> To recap a bit of the context from that series, in OpenBMC there's a
>> need for certain devices (described by device-tree nodes) to be able
>> to be attached and detached at runtime (for example the SPI flash for
>> the host's firmware, which is shared between the BMC and the host but
>> can only be accessed by one or the other at a time).
>
>This seems quite dangerous. Why do you need that? 

Sometimes the host needs access to the flash (it's the host's firmware, 
after all), sometimes the BMC needs access to it (e.g. to perform an 
out-of-band update to the host's firmware).  To achieve the latter, the 
flash needs to be attached to the BMC, but that requires some careful 
coordination with the host to arbitrate which one actually has access to 
it (that coordination is handled by userspace, which then tells the 
kernel explicitly when the flash should be attached and detached).

What seems dangerous?

>Why can't device tree overlays be used?

I'm hoping to stay closer to mainline.  The OpenBMC kernel has a 
documented policy strongly encouraging upstream-first development: 
https://github.com/openbmc/docs/blob/master/kernel-development.md

I doubt Joel (the OpenBMC kernel maintainer) would be eager to start 
carrying the DT overlay patches; I'd likewise strongly prefer to avoid 
carrying them myself as additional downstream patches.  Hence the 
attempt at getting a solution to the problem upstream.

>
>> To provide that
>> ability, this series adds support for a new common device-tree
>> property, a boolean "dynamic" that indicates that the device may come
>> and go at runtime.  When present on a node, the sysfs file for that
>> node's "status" property is made writable, allowing userspace to do
>> things like:
>>
>>   $ echo okay > /sys/firmware/devicetree/.../status
>>   $ echo reserved > /sys/firmware/devicetree/.../status
>>
>> to activate and deactivate a dynamic device.
>>
>> Because it leans on the OF_DYNAMIC machinery internally, this
>> functionality will only work on busses that register for OF reconfig
>> notifications and handle them appropriately (presently platform, i2c,
>> and spi).  This series does not attempt to solve the "dynamic devices
>> further down the tree" problem [2]; my hope is that handling for OF
>> reconfig notifications can be extended to other families of devices
>> (e.g. individual MTD spi-nor flash chips) in the future.
>
>What about ACPI and software nodes?

I'm afraid I don't understand the question, can you elaborate on what 
you mean?

>How will all this affect the host?

Assuming the coordination mentioned above is done properly, the host 
will be in a quiesced state whenever the BMC is accessing the flash and 
hence won't notice much of anything at all (the BMC will detach the 
flash and relinquish control of it back to the host before the host is 
reactivated).


Zev


  reply	other threads:[~2021-10-07  9:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07  0:09 Zev Weiss
2021-10-07  0:09 ` [PATCH 1/9] sysfs: add sysfs_remove_bin_file_self() function Zev Weiss
2021-10-07  5:23   ` Greg Kroah-Hartman
2021-10-07  5:58     ` Zev Weiss
2021-10-07  6:12       ` Greg Kroah-Hartman
2021-10-07  6:55         ` Zev Weiss
2021-10-07  0:09 ` [PATCH 2/9] sysfs: add growable flag to struct bin_attribute Zev Weiss
2021-10-07  0:09 ` [PATCH 3/9] lib/string: add sysfs_buf_streq() Zev Weiss
2021-10-07  0:09 ` [PATCH 4/9] of: add self parameter to __of_sysfs_remove_bin_file() Zev Weiss
2021-10-07  5:25   ` Greg Kroah-Hartman
2021-10-07  0:09 ` [PATCH 5/9] of: add self parameter to of_update_property() Zev Weiss
2021-10-07  5:26   ` Greg Kroah-Hartman
2021-10-07  0:09 ` [PATCH 6/9] of: add support for 'dynamic' DT property Zev Weiss
2021-10-08 18:51   ` Frank Rowand
2021-10-08 19:19     ` Frank Rowand
2021-10-11 13:58     ` Frank Rowand
2021-10-11 14:46       ` Frank Rowand
2021-10-11 17:35       ` Zev Weiss
2021-10-07  0:09 ` [PATCH 7/9] of: make OF_DYNAMIC selectable independently of OF_UNITTEST Zev Weiss
2021-10-08 19:01   ` Frank Rowand
2021-10-07  0:09 ` [PATCH 8/9] dt-bindings: document new 'dynamic' common property Zev Weiss
2021-10-07  5:26   ` Greg Kroah-Hartman
2021-10-07  6:03     ` Zev Weiss
2021-10-07  0:09 ` [PATCH 9/9] ARM: dts: aspeed: Add e3c246d4i BIOS flash device Zev Weiss
2021-10-07  2:46 ` [PATCH 0/9] Dynamic DT device nodes Florian Fainelli
2021-10-07  5:44   ` Zev Weiss
2021-10-07  7:04 ` Andy Shevchenko
2021-10-07  9:05   ` Zev Weiss [this message]
2021-10-07 10:31     ` Greg Kroah-Hartman
2021-10-07 15:41       ` Zev Weiss
2021-10-07 20:03         ` Rob Herring
2021-10-08  5:41           ` Greg Kroah-Hartman
2021-10-08 19:43           ` 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=YV64ZbcsHvBObH2j@hatter.bewilderbeest.net \
    --to=zev@bewilderbeest.net \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@aj.id.au \
    --cc=andreyknvl@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dja@axtens.net \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=jk@codeconstruct.com.au \
    --cc=keescook@chromium.org \
    --cc=kw@linux.com \
    --cc=laniel_francis@privacyrequired.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --subject='Re: [PATCH 0/9] Dynamic DT device nodes' \
    /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).