* [PATCH 0/9] Dynamic DT device nodes @ 2021-10-07 0:09 Zev Weiss 2021-10-07 0:09 ` [PATCH 9/9] ARM: dts: aspeed: Add e3c246d4i BIOS flash device Zev Weiss ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Zev Weiss @ 2021-10-07 0:09 UTC (permalink / raw) To: openbmc Cc: Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Zev Weiss, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, linux-kernel, linux-arm-kernel, linux-aspeed Hello, 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). 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. The central change of the series is patch 6; patches 1-5 are various small infrastructure bits and plumbing tweaks in preparation for #6; patches 7-9 are Kconfig, documentation, and an inaugural use of the new property in the ASRock e3c246d4i BMC device tree. Note that this series requires the duplicate-declaration removal patch that was recently merged in Rob's tree [3]; it changes one of the duplicated declarations and hence will not compile without that patch (because the declarations no longer match). [0] https://lore.kernel.org/openbmc/20210929115409.21254-1-zev@bewilderbeest.net/ [1] https://lore.kernel.org/openbmc/CAL_JsqJH+b5oFuSP+KBLBsN5QTA6xASuqXJWXUaDkHhugXPpnQ@mail.gmail.com/ [2] https://lore.kernel.org/openbmc/20210929220038.GS17315@packtop/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?id=6663ae07d995f5fbe2988a19858b2f87e68cf929 Zev Weiss (9): sysfs: add sysfs_remove_bin_file_self() function sysfs: add growable flag to struct bin_attribute lib/string: add sysfs_buf_streq() of: add self parameter to __of_sysfs_remove_bin_file() of: add self parameter to of_update_property() of: add support for 'dynamic' DT property of: make OF_DYNAMIC selectable independently of OF_UNITTEST dt-bindings: document new 'dynamic' common property ARM: dts: aspeed: Add e3c246d4i BIOS flash device .../devicetree/bindings/common-properties.txt | 18 ++++ .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 23 ++++++ drivers/of/Kconfig | 8 +- drivers/of/base.c | 7 +- drivers/of/dynamic.c | 2 +- drivers/of/kobj.c | 82 +++++++++++++++++-- drivers/of/of_private.h | 6 +- fs/sysfs/file.c | 15 +++- include/linux/of.h | 7 +- include/linux/string.h | 1 + include/linux/sysfs.h | 2 + lib/string.c | 34 ++++++++ 12 files changed, 187 insertions(+), 18 deletions(-) -- 2.33.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 9/9] ARM: dts: aspeed: Add e3c246d4i BIOS flash device 2021-10-07 0:09 [PATCH 0/9] Dynamic DT device nodes Zev Weiss @ 2021-10-07 0:09 ` Zev Weiss 2021-10-07 2:46 ` [PATCH 0/9] Dynamic DT device nodes Florian Fainelli 2021-10-07 7:04 ` Andy Shevchenko 2 siblings, 0 replies; 11+ messages in thread From: Zev Weiss @ 2021-10-07 0:09 UTC (permalink / raw) To: openbmc Cc: Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Zev Weiss, Andrew Jeffery, linux-arm-kernel, linux-aspeed, linux-kernel This uses a dynamic DT node because the BIOS SPI flash requires significant coordination with the host system (power state tracking, GPIOs, IPMI messages) before the BMC can touch it, and needs to be relinquished back to the host when the BMC is done accessing it. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> --- .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts index 9b4cf5ebe6d5..428198703824 100644 --- a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts @@ -68,6 +68,29 @@ flash@0 { }; }; +&spi1 { + /* + * The BIOS SPI flash is shared with the host via an external mux, and + * is not accessible by the BMC by default (hence reserved/dynamic + * here rather than okay). This would ideally be done on the flash@0 + * node instead of the spi1 controller, but the driver infrastructure + * to support dynamic devices at that level of the device tree isn't + * currently in place, and it's the only flash chip on this + * controller, so we can get away with the coarser granularity here + * until support for making individual flash chips dynamic is + * available. + */ + status = "reserved"; + dynamic; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_spi1_default>; + flash@0 { + status = "okay"; + label = "bios"; + m25p,fast-read; + }; +}; + &uart5 { status = "okay"; }; -- 2.33.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 0:09 [PATCH 0/9] Dynamic DT device nodes 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 ` Florian Fainelli 2021-10-07 5:44 ` Zev Weiss 2021-10-07 7:04 ` Andy Shevchenko 2 siblings, 1 reply; 11+ messages in thread From: Florian Fainelli @ 2021-10-07 2:46 UTC (permalink / raw) To: Zev Weiss, openbmc Cc: Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, linux-kernel, linux-arm-kernel, linux-aspeed On 10/6/2021 5:09 PM, Zev Weiss wrote: > Hello, > > 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). 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. This is a completely drive by comment here, but cannot you already achieve what you want today by making the SPI-NOR to be loaded as a module, probe it when you need it from the BMC, and unbind or rmmod the drive when you need it on the server/host attached to the BMC? Looking at [0] there appears to be enough signaling visible by the BMC's user-space that it ought to be possible? Assuming that there may be multiple flash chips and you somehow need to access one in order to complete the BMC device boot, but not the other one(s), you could imagine unbinding the spi-nor driver from the ones you don't want to drive and wait until you have appropriate signaling made available to your or is there a risk of racing with the host in doing so? -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 2:46 ` [PATCH 0/9] Dynamic DT device nodes Florian Fainelli @ 2021-10-07 5:44 ` Zev Weiss 0 siblings, 0 replies; 11+ messages in thread From: Zev Weiss @ 2021-10-07 5:44 UTC (permalink / raw) To: Florian Fainelli Cc: openbmc, Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, linux-kernel, linux-arm-kernel, linux-aspeed On Wed, Oct 06, 2021 at 07:46:08PM PDT, Florian Fainelli wrote: > > >On 10/6/2021 5:09 PM, Zev Weiss wrote: >>Hello, >> >>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). 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. > >This is a completely drive by comment here, but cannot you already >achieve what you want today by making the SPI-NOR to be loaded as a >module, probe it when you need it from the BMC, and unbind or rmmod >the drive when you need it on the server/host attached to the BMC? > >Looking at [0] there appears to be enough signaling visible by the >BMC's user-space that it ought to be possible? > >Assuming that there may be multiple flash chips and you somehow need >to access one in order to complete the BMC device boot, but not the >other one(s), you could imagine unbinding the spi-nor driver from the >ones you don't want to drive and wait until you have appropriate >signaling made available to your or is there a risk of racing with the >host in doing so? Hi Florian, I sort of considered similar things at various points (in fact the bind/unbind technique is what I've been using as a stopgap so far), but I don't think it's ultimately a great solution. In this particular case it happens that the driver for the host's BIOS flash (aspeed-smc) is the same driver used for the BMC's firmware flash and hence necessary for it to boot. (OpenBMC also typically uses a non-modular kernel, for what it's worth.) On BMC startup we don't know the state of the host, and while the mux that ultimately determines which processor has access to the BIOS flash defaults to connecting it to the host (so if we do attempt to attach it we'll simply fail clumsily and spew some errors to dmesg rather than causing catastrophic errors host-side), blindly starting to poke the BIOS flash without doing the proper coordination with the host first seems to me to be pretty squarely in the category of "things we shouldn't be doing" -- the desire to avoid that sort of clunkiness is a significant portion of what led me to pursue a better solution in the first place. Additionally, while I don't know the details of the specific hardware involved, others in the OpenBMC community (or at least Andrew Jeffery) have indicated that pluggable DT devices would be useful for the systems they're working on as well, I suspect for things other than host firmware flashes. Zev _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 0:09 [PATCH 0/9] Dynamic DT device nodes 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 7:04 ` Andy Shevchenko 2021-10-07 9:05 ` Zev Weiss 2 siblings, 1 reply; 11+ messages in thread From: Andy Shevchenko @ 2021-10-07 7:04 UTC (permalink / raw) To: Zev Weiss Cc: OpenBMC Maillist, Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT 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? Why can't device tree overlays be used? > 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? How will all this affect the host? > [0] https://lore.kernel.org/openbmc/20210929115409.21254-1-zev@bewilderbeest.net/ > [1] https://lore.kernel.org/openbmc/CAL_JsqJH+b5oFuSP+KBLBsN5QTA6xASuqXJWXUaDkHhugXPpnQ@mail.gmail.com/ > [2] https://lore.kernel.org/openbmc/20210929220038.GS17315@packtop/ > [3] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?id=6663ae07d995f5fbe2988a19858b2f87e68cf929 -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 7:04 ` Andy Shevchenko @ 2021-10-07 9:05 ` Zev Weiss 2021-10-07 10:31 ` Greg Kroah-Hartman 0 siblings, 1 reply; 11+ messages in thread From: Zev Weiss @ 2021-10-07 9:05 UTC (permalink / raw) To: Andy Shevchenko Cc: OpenBMC Maillist, Greg Kroah-Hartman, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 9:05 ` Zev Weiss @ 2021-10-07 10:31 ` Greg Kroah-Hartman 2021-10-07 15:41 ` Zev Weiss 0 siblings, 1 reply; 11+ messages in thread From: Greg Kroah-Hartman @ 2021-10-07 10:31 UTC (permalink / raw) To: Zev Weiss Cc: Andy Shevchenko, OpenBMC Maillist, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT On Thu, Oct 07, 2021 at 02:05:41AM -0700, Zev Weiss wrote: > 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. Then why not work to get device tree overlays to be merged properly? Don't work on a half-of-a-solution when the real solution is already here. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 10:31 ` Greg Kroah-Hartman @ 2021-10-07 15:41 ` Zev Weiss 2021-10-07 20:03 ` Rob Herring 0 siblings, 1 reply; 11+ messages in thread From: Zev Weiss @ 2021-10-07 15:41 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Andy Shevchenko, OpenBMC Maillist, Jeremy Kerr, Joel Stanley, Rob Herring, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT On Thu, Oct 07, 2021 at 03:31:39AM PDT, Greg Kroah-Hartman wrote: >On Thu, Oct 07, 2021 at 02:05:41AM -0700, Zev Weiss wrote: >> 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. > >Then why not work to get device tree overlays to be merged properly? >Don't work on a half-of-a-solution when the real solution is already >here. > I had been under the impression that the overlay patches had very dim prospects of ever being accepted and that this might be a more tractable alternative, but apparently was mistaken -- I'll look into what the outstanding issues were with that and perhaps take a stab at addressing them. Zev _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 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 0 siblings, 2 replies; 11+ messages in thread From: Rob Herring @ 2021-10-07 20:03 UTC (permalink / raw) To: Zev Weiss, Greg Kroah-Hartman Cc: Andy Shevchenko, OpenBMC Maillist, Jeremy Kerr, Joel Stanley, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT On Thu, Oct 7, 2021 at 10:41 AM Zev Weiss <zev@bewilderbeest.net> wrote: > > On Thu, Oct 07, 2021 at 03:31:39AM PDT, Greg Kroah-Hartman wrote: > >On Thu, Oct 07, 2021 at 02:05:41AM -0700, Zev Weiss wrote: > >> 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. > > > >Then why not work to get device tree overlays to be merged properly? TBC, it's 'just' the general purpose userspace interface to apply overlays that's missing. I did suggest what's done here as overlays are kind of an overkill for this usecase. Much easier to write to a sysfs file than write an overlay, compile it with dtc, and provide it to the kernel all just to enable a device. Perhaps this could also be supported in the driver model directly. Given the "what about ACPI question", that is probably what should be done unless the answer is we don't care. I think we'd just need a flag to create devices, but not bind automatically. Or maybe abusing driver_override can accomplish that. > >Don't work on a half-of-a-solution when the real solution is already > >here. > > > > I had been under the impression that the overlay patches had very dim > prospects of ever being accepted and that this might be a more tractable > alternative, but apparently was mistaken -- I'll look into what the > outstanding issues were with that and perhaps take a stab at addressing > them. What's dim is the patches allowing any modification to any part of the DT. Any changes to a DT need to work (i.e. have some effect). For example, randomly changing/adding/removing properties wouldn't have any effect because they've probably already be read and used. What I've suggested before is some sort of registration of nodes allowed to apply child nodes and properties to. That would serve the add-on board usecases which have been the main driver of this to date. That also got hung up on defining interface nodes to add-on boards. Your scope is more limited and can be limited to that scope while using the same configfs interface. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 20:03 ` Rob Herring @ 2021-10-08 5:41 ` Greg Kroah-Hartman 2021-10-08 19:43 ` Frank Rowand 1 sibling, 0 replies; 11+ messages in thread From: Greg Kroah-Hartman @ 2021-10-08 5:41 UTC (permalink / raw) To: Rob Herring Cc: Zev Weiss, Andy Shevchenko, OpenBMC Maillist, Jeremy Kerr, Joel Stanley, devicetree, Andrew Jeffery, Frank Rowand, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT On Thu, Oct 07, 2021 at 03:03:43PM -0500, Rob Herring wrote: > On Thu, Oct 7, 2021 at 10:41 AM Zev Weiss <zev@bewilderbeest.net> wrote: > > > > On Thu, Oct 07, 2021 at 03:31:39AM PDT, Greg Kroah-Hartman wrote: > > >On Thu, Oct 07, 2021 at 02:05:41AM -0700, Zev Weiss wrote: > > >> 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. > > > > > >Then why not work to get device tree overlays to be merged properly? > > TBC, it's 'just' the general purpose userspace interface to apply > overlays that's missing. > > I did suggest what's done here as overlays are kind of an overkill for > this usecase. Much easier to write to a sysfs file than write an > overlay, compile it with dtc, and provide it to the kernel all just to > enable a device. > > Perhaps this could also be supported in the driver model directly. > Given the "what about ACPI question", that is probably what should be > done unless the answer is we don't care. I think we'd just need a flag > to create devices, but not bind automatically. Or maybe abusing > driver_override can accomplish that. The driver model already allows devices to be bound/unbound from drivers, but no, it does not allow new devices to be "created" from userspace as that is a very bus-specific thing to have happen. If this is "just" a platform device, perhaps add that logic to the platform bus code? thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Dynamic DT device nodes 2021-10-07 20:03 ` Rob Herring 2021-10-08 5:41 ` Greg Kroah-Hartman @ 2021-10-08 19:43 ` Frank Rowand 1 sibling, 0 replies; 11+ messages in thread From: Frank Rowand @ 2021-10-08 19:43 UTC (permalink / raw) To: Rob Herring, Zev Weiss, Greg Kroah-Hartman Cc: Andy Shevchenko, OpenBMC Maillist, Jeremy Kerr, Joel Stanley, devicetree, Andrew Jeffery, Rafael J. Wysocki, Andy Shevchenko, Andrew Morton, Francis Laniel, Kees Cook, Andrey Konovalov, Jonathan Cameron, Daniel Axtens, Alexey Dobriyan, Dan Williams, Daniel Vetter, Krzysztof Wilczyński, Heiner Kallweit, Nick Desaulniers, Linux Kernel Mailing List, linux-arm Mailing List, moderated list:ARM/ASPEED MACHINE SUPPORT On 10/7/21 3:03 PM, Rob Herring wrote: > On Thu, Oct 7, 2021 at 10:41 AM Zev Weiss <zev@bewilderbeest.net> wrote: >> >> On Thu, Oct 07, 2021 at 03:31:39AM PDT, Greg Kroah-Hartman wrote: >>> On Thu, Oct 07, 2021 at 02:05:41AM -0700, Zev Weiss wrote: >>>> 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. >>> >>> Then why not work to get device tree overlays to be merged properly? > > TBC, it's 'just' the general purpose userspace interface to apply > overlays that's missing. A fuller view of what is missing is at: https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts#issues_and_what_needs_to_be_completed_--_Not_an_exhaustive_list > > I did suggest what's done here as overlays are kind of an overkill for > this usecase. Much easier to write to a sysfs file than write an > overlay, compile it with dtc, and provide it to the kernel all just to > enable a device. > > Perhaps this could also be supported in the driver model directly. > Given the "what about ACPI question", that is probably what should be > done unless the answer is we don't care. I think we'd just need a flag > to create devices, but not bind automatically. Or maybe abusing > driver_override can accomplish that. > >>> Don't work on a half-of-a-solution when the real solution is already >>> here. >>> >> >> I had been under the impression that the overlay patches had very dim >> prospects of ever being accepted and that this might be a more tractable >> alternative, but apparently was mistaken -- I'll look into what the >> outstanding issues were with that and perhaps take a stab at addressing >> them. > > What's dim is the patches allowing any modification to any part of the > DT. Any changes to a DT need to work (i.e. have some effect). For > example, randomly changing/adding/removing properties wouldn't have > any effect because they've probably already be read and used. Yes, that is a good description. > > What I've suggested before is some sort of registration of nodes > allowed to apply child nodes and properties to. That would serve the > add-on board usecases which have been the main driver of this to date. > That also got hung up on defining interface nodes to add-on boards. > Your scope is more limited and can be limited to that scope while > using the same configfs interface. > > Rob > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-10-08 19:45 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-07 0:09 [PATCH 0/9] Dynamic DT device nodes 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 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
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).