Received: by 2002:ac0:c50a:0:0:0:0:0 with SMTP id y10csp1372984imi; Fri, 1 Jul 2022 08:27:39 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZG5CmtI/0n82faqj+pQIGABXksuV9GzvevlrMPBQbXuM71BH1OF0pA/5+18xqQfezu3y5 X-Received: by 2002:a05:6402:1e93:b0:435:7f3f:407f with SMTP id f19-20020a0564021e9300b004357f3f407fmr19908248edf.173.1656689258944; Fri, 01 Jul 2022 08:27:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656689258; cv=none; d=google.com; s=arc-20160816; b=fyRJ2aXW2JXjFjLkCxyQXw3q5th3U1f1ZDvmEN94/Fy4rCaKQqOWXJZadn6YaFSTyX xB1jeR5+o6ggJqn0q7+RAi/4cppqJJMOPfxw0QrKYnDCWsniIrLVnhZCJFabKOUPvRzL XYBnVva1NnNdNtQr2T9VZnJKs89lesbs3Nzn2yLhwPgVES/1n2a3qBFXjkg31wENSJJS sC9IKWZVSat5eZKJ3e8AfODV0heJo8bFL3e6+HFbrqJNTaDpOgmVb49Bm5MhaGIXdOFP NGn/lvK9tZ8kkN3G+G7g3SbnN159w6HZ1m/VuArOQ5Mtt9gZLjYW19Hps9gyy0EtkS7p jlBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ZP7e6ZrR3Se8CD2YjhmJ+GjEzbdhM5RCyddln7B7EY8=; b=KqnbM1toXZF6+Al2FE35sw/CtIyCDGe0w2Xu9c33urD+qI9uo7IMczYZlZG11CStlb L7QLqCn32wZoRf4unnv9asunLKBikB7ecv7ZFuwFMZuGovpB5UCIBE5RiASdVwJc4RnM wlmCukbGypZ+j5ahVyLmg/oLaWskDS7tTtonz6Ig48j4+xey0FoF5Y+MWm5/2ulRzfZO zhsnaIfxIlJtp09LM0Ae9/mIoizJy5gjwqpm04njw+qI8/v7JYrbSeK/CKUMk7syvs48 r8R0BEpAwLWxSzY3RkYwS4hTdSGVu6DN5wTC2GEQSLBqo+HmxGobPWCAfdbcEbPim8CG PMFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw7-20020a170906478700b00718cc1814aasi3158980ejc.845.2022.07.01.08.27.13; Fri, 01 Jul 2022 08:27:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232006AbiGAOro (ORCPT + 99 others); Fri, 1 Jul 2022 10:47:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232024AbiGAOr2 (ORCPT ); Fri, 1 Jul 2022 10:47:28 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 008701658A for ; Fri, 1 Jul 2022 07:47:24 -0700 (PDT) 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 EA541143D; Fri, 1 Jul 2022 07:47:24 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D082B3F792; Fri, 1 Jul 2022 07:47:22 -0700 (PDT) Date: Fri, 1 Jul 2022 15:47:20 +0100 From: Cristian Marussi To: Sudeep Holla Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.quinlan@broadcom.com, Jonathan.Cameron@huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, daniel.lezcano@linaro.org, tarek.el-sherbiny@arm.com, adrian.slatineanu@arm.com, souvik.chakravarty@arm.com, wleavitt@marvell.com, wbartczak@marvell.com Subject: Re: [PATCH v3 5/9] firmware: arm_scmi: Make use of FastChannels configurable Message-ID: References: <20220627123038.1427067-1-cristian.marussi@arm.com> <20220627123038.1427067-6-cristian.marussi@arm.com> <20220701140307.upgfn4qpxhl63syg@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220701140307.upgfn4qpxhl63syg@bogus> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 01, 2022 at 03:03:07PM +0100, Sudeep Holla wrote: > On Mon, Jun 27, 2022 at 01:30:34PM +0100, Cristian Marussi wrote: > > Add a Kernel configuration entry used to optionally disable, globally, the > > usage of SCMI FastChannels even on platforms where they are available. > > > > Make such option default-no to preserve the original SCMI system behaviour > > of using any available FC. > > > > Signed-off-by: Cristian Marussi > > --- > > v2 --> v3 > > - fixed wording in Kconfig > > - reverted Kconfig logic _USE_ -> _AVOID_ > > --- > > drivers/firmware/arm_scmi/Kconfig | 13 +++++++++++++ > > drivers/firmware/arm_scmi/driver.c | 6 ++++++ > > 2 files changed, 19 insertions(+) > > > > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig > > index 1e7b7fec97d9..3fb34db01014 100644 > > --- a/drivers/firmware/arm_scmi/Kconfig > > +++ b/drivers/firmware/arm_scmi/Kconfig > > @@ -42,6 +42,19 @@ config ARM_SCMI_HAVE_MSG > > This declares whether a message passing based transport for SCMI is > > available. > > > > +config ARM_SCMI_AVOID_FASTCHANNELS > > + bool "Avoid using SCMI FastChannels even when available" > > Without default, won't this prompt user now ? I would have explicit default n > if we are adding this. But why do we need this is my question ? This would > be a quirk IMO on systems where FC is broken. I don't want people to enable > this during testing and ship f/w with FC broken(or not developed yet). > > We can add this if some platforms really need this as a quirk in the future. > Ah ok an explicit default no is better indeed to avoid prompting if you do not defconfig (I missed this difference between default implicit NO and explicit NO) ... ... regarding why, I am using personally this indeed for testing with or without FCs without having to change the installed FW blob, BUT the reason for upstreaming such an option is that FC support is indeed optional by the spec so I thought it would have been acceptabel that you could want to configure a platform NOT to use them even though the FW implementation you are using, maybe across multiple platforms, supports it. Thanks, Cristian