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 31A00CD6E71 for ; Wed, 11 Oct 2023 13:42:16 +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=NBB+ydtoYkT/10gyjhLejSQCMLCXkwV8edR/4ImLP2o=; b=Je9FzPOHDjpomD Xp6LMk9f7vnmdWVh1Ci7nMd/JRNFqtErOCGEnQDGcWbYx4DrYnvdSnWP0eifrfXoZK0tRWezV4Eie rSQ31GXQi3o7CLwYlnBor2uAi8zgCNp7kL5x2XSi07MoFp4fD7UV6WLpadmt7bsoKdgAjqN6Glpg8 aW+2jhBl5uDpeWsW8JsJKJn72yXuWKSEf0XsKu6hUw1wIUjq7V5aNPFn+4kgFw5P5qOtoiDCtAgIy zTeusdboqvpNiJtI+aqdqBcPWK6EsqSiLMJGf9uYjfLC6tKp/claHSlKcXtZuhupxdj3qYr6dr5js MnGxX9uJLC4EvH2jFb9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qqZT8-00G0LK-1a; Wed, 11 Oct 2023 13:41:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qqZT4-00G0JI-1H for linux-arm-kernel@lists.infradead.org; Wed, 11 Oct 2023 13:41:44 +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 8121EC15; Wed, 11 Oct 2023 06:42:18 -0700 (PDT) Received: from bogus (unknown [10.57.93.106]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C229D3F5A1; Wed, 11 Oct 2023 06:41:35 -0700 (PDT) Date: Wed, 11 Oct 2023 14:40:03 +0100 From: Sudeep Holla To: Ranjani Vaidyanathan Cc: Cristian Marussi , "Peng Fan (OSS)" , Sudeep Holla , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "souvik.chakravarty@arm.com" , Glen G Wienecke , Peng Fan Subject: Re: [EXT] Re: [RFC] firmware: arm_scmi: clock: add fixed clock attribute support Message-ID: <20231011134003.lhb5yiicgr5cbzr2@bogus> References: <20231010022911.4106863-1-peng.fan@oss.nxp.com> <20231010091223.rvcyrgbjcrmjzmvp@bogus> <20231010093509.ddy75og4jd72n6cq@bogus> 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-20231011_064142_496452_40EB2C40 X-CRM114-Status: GOOD ( 18.97 ) 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 Wed, Oct 11, 2023 at 03:54:59AM +0000, Ranjani Vaidyanathan wrote: > From what I see SCMI clock protocol could benefit from an attribute for the > clock that describes what operations are possible on a clock. There are many > bus clocks that only the SCMI server manages and the error code DENIED > should be handled gracefully by the agent. > Agreed, but we need to understand if we need it per operation basis or at the higher granularity such as any write or set operations not allowed. Just my initial thoughts, we can discuss. > In the case of Linux, perhaps this should be handled by the SCMI clock > driver, instead of allowing the error to propagate up the Linux clock > framework? Yes but even for that we need information from the firmware. > It seems strange that the SCMI server should swallow the error (silently > fail) only for certain agents. I am bit confused by this statement. The SCMI server/platform must not ignore or fail silently. Since the agent is not allowed, if it attempts it must return the apt error. While Linux may choose to ignore the error but I think this is what we are discussing to figure out what is the best way to avoid it or worst case handle it gracefully. With any extra info from the firmware, the former option must be possible and we need not think of the latter option IMO. > I would think this would make debug quite difficult and having a "DENIED" > error code not very useful. > Agreed especially if it can and is expected to continue functioning as normal. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel