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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4C597C25B08 for ; Wed, 17 Aug 2022 08:40:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type: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=vPTlDet71megAFTgNKLKTH4fcj2p89R9d4v7HqnWQlY=; b=duSAA59ml7OO+k ZOkCDgfAaKar1ase5sc8gHa3gQFbpk6MthpLJpShljJvUiSVCUwHXJNcJ6r7nxIFlhyUcEp7rVlb9 waDYy93vt/MfoQZwDUizF6jutR4Of5DKca7c/PVU+sa+/gV0HQp0BBprYS3taLKg3JZ9TDYTVobhj ZpGTV7bQBAkwJQt2HNH6VLZTfBYxKfxp9HpxTxAsiGi1y9Du78PU03mh+1GykHyDsEADWhY8WnNn2 QXJ3ohUOpj/sCIs3uOiZzI0SNVv8MuCZjqPWBG+xTjfIX+e9UF9ld/D7G6H/i4nreRJkHXbyeRjG0 pZpS92Mm3qCQop6Rh2vA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOEa3-00FRXt-LC; Wed, 17 Aug 2022 08:39:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOEZz-00FRP8-Kv for linux-arm-kernel@lists.infradead.org; Wed, 17 Aug 2022 08:39:13 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C64B5106F; Wed, 17 Aug 2022 01:39:05 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 459F53F70D; Wed, 17 Aug 2022 01:39:03 -0700 (PDT) Date: Wed, 17 Aug 2022 09:38:57 +0100 From: Cristian Marussi To: Mark Brown Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, wleavitt@marvell.com, peter.hilber@opensynergy.com, nicola.mazzucato@arm.com, tarek.el-sherbiny@arm.com Subject: Re: [RFC PATCH 5/6] firmware: arm_scmi: Add raw transmission support Message-ID: References: <20220816072450.3120959-1-cristian.marussi@arm.com> <20220816072450.3120959-6-cristian.marussi@arm.com> 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-20220817_013911_815760_7EC4E265 X-CRM114-Status: GOOD ( 26.81 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 16, 2022 at 07:03:21PM +0100, Mark Brown wrote: > On Tue, Aug 16, 2022 at 08:24:49AM +0100, Cristian Marussi wrote: > > Add SCMI Raw mode support which exposes a userspace interface rooted under > > /sys/kernel/debug/scmi_raw. Hi Mark, thanks for having a look. > > > Raw mode can be enabled/disabled at runtime via ./scmi_raw/enable. > > Once enabled, all the regular SCMI drivers activity is inhibited and a > > userspace application can then inject and read back bare SCMI messages > > writing and reading to/from ./scmi_raw/message* entries. > > Is there a strong reason to have the runtime enable/disable? Given that > this is going to be used in special kernel builds rather than something > people have as standard it feels like the transition to/from raw mode is > opening up a set of extra use cases that wouldn't normally come up for > the SCMI drivers (especially if the testing ends up leaving the firmware > in a weird state). The rationale for this dynamic runtime switch was to try to have a system that can be configured for SCMI FW testing BUT not necessarily specifically only for such SCMI tests...IOW a system that can be used in CI to run a number of other test suites (while in normal mode) and then switched to raw mode only when SCMI compliance tests are to be run. Indeed, the enable/disable thing is the main critical point of this RFC since especially the disable-and-back-to-normal transition proved to be potentially problematic...i.e. the system generally works in my setup but it cannot be guaranteed to really bring back the system in a fully functional state depending on how complex the driver stack is (..beside the potential FW final weird state issue as you rightly pointed out) ...moreover at the end the whole disable and go-back-to-normal really makes little sense in a typical CI scenario where anyway the system under test is most probably rebooted between runs of different test suites, so we really do not care about any weird final state probably. I, nonetheless, posted this RFC with this such support, at first to have some general feedback, BUT also because I'm still anyway wondering if it would not be worth to keep at least the capability to only enable it at run-time (dropping the disable-back-to-normal feat), because this would enable to build an image which includes this SCMI Raw support, which is default disabled, and that can at will enabled at runtime only on selected runs, so that this same test-image could still be used in a number of different CI test-runs (keeping raw mode disabled and silent) but also then used for a specific SCMI testing run that would eventually enable it. If this is not worth really I can just drop the whole runtime switch thing and stick to the more conservative approach of having a dedicated image for this kind of SCMI FW testing: a system that once configured at compile time with this, it just cannot use at all the regular SCMI stack (...which does NOT necessarily prevent the system to boot and be used for other non SCMI testing indeed...it would just be probably slower...) Any thought ? Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel