From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E2E9C433EF for ; Thu, 7 Oct 2021 09:07:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CEF6B600CD for ; Thu, 7 Oct 2021 09:07:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CEF6B600CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bewilderbeest.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AKqESxTpVAvpeLKsSoiDrqBCsVyi5QgEo6bc7esIkXo=; b=vrpi9I003go+OpSTtarF/GjPsx uMRXBlvZsQ8+4A/QhH+wcDWKNsfQBMgrLuTeih2M9jwca6bCQ2FlPNwvCuh8QFQVxiW2Mn1uuWAg/ vUzt1mQRywFpriZbTK4jG9S50mdEpZuhyBeyREPHq3bNVewjA0xIQGq2SbmVYzBUOHph8Ij8T3+6L iFNKTCn5gv3UtRnZ0bkGEADI8Bs3ID1rkbUkihV97Iqa59eWDPPqFdMX1oHIHvJZJbqOyhakmRrST dAQZBOPmnF6RHN12RUZ3eK9fBB59qA2X4HbPhOAnpk46PmOtmhpQN4gz40kmVgXAZXLC2vujNhVhS 6P1sQb6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYPLd-00GeCo-3p; Thu, 07 Oct 2021 09:05:53 +0000 Received: from thorn.bewilderbeest.net ([2605:2700:0:5::4713:9cab]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYPLa-00GeCA-0M for linux-arm-kernel@lists.infradead.org; Thu, 07 Oct 2021 09:05:51 +0000 Received: from hatter.bewilderbeest.net (71-212-29-146.tukw.qwest.net [71.212.29.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id B54F0F6; Thu, 7 Oct 2021 02:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1633597547; bh=m8q3ivL4JNCs32ZTM2MObocXXvZZ0W1tFJVUtNGkFTo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bHul7hklIuebeh7G55Y6p0NYVNaTJUWiM8AusuYh/yvLMc68T/jZr57bQqtm137Qx TTowiEFnPLLwhTTzX6T53EhX5grk/BiRFRiPNcRwk7NruSlyTjHZz7msTpDRr47dFu fQA8Vvc9186bmCEsWWzYAuF+qPu9L4x1tcyk0+VE= Date: Thu, 7 Oct 2021 02:05:41 -0700 From: Zev Weiss 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 =?utf-8?Q?Wilczy=C5=84ski?= , Heiner Kallweit , Nick Desaulniers , Linux Kernel Mailing List , linux-arm Mailing List , "moderated list:ARM/ASPEED MACHINE SUPPORT" Subject: Re: [PATCH 0/9] Dynamic DT device nodes Message-ID: References: <20211007000954.30621-1-zev@bewilderbeest.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211007_020550_078670_2778CC48 X-CRM114-Status: GOOD ( 30.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 07, 2021 at 12:04:41AM PDT, Andy Shevchenko wrote: >On Thu, Oct 7, 2021 at 3:10 AM Zev Weiss 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