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 732C7CD11DD for ; Wed, 27 Mar 2024 12:21:06 +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=N5CslOmtMZrkCIcviLd8UrufRwS7e1kUVtvAdQB8874=; b=FWpJmhQGJNuJyR hqkobo0JPW4q0ltpqPCsOaeNHhpjDB8yarFWVaXxYfe8foeNJxJcKj6N/FH8m7UgGukz9TyKcRIhf mV1ITYw/jR6CAR7kxFI1VTR2GtH8Tw1m0hcqTL0Oa5Gf/qgeqW7sWgvSWYqLkcUpIYg8D46YkUxp2 /Ulshkk3MSupVoDCJTH4Rf72B9TI/bitrbS/OKy1NqSSFi/1oQ4QmQW5UlZNld7ypflOUeXLkTq6P zS+zB7nP+wwPAMjfqNNNMvoEPVkFdGPKd8V1nxm1+PcdJfinP+fpPXduMgzEhw9XCyZ5sHP4S5CnB qOWn9BT4iBAneYp2L+8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpSGy-00000008oSj-3TWz; Wed, 27 Mar 2024 12:20:52 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpSGv-00000008oPa-3DFr for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2024 12:20:51 +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 8463E2F4; Wed, 27 Mar 2024 05:21:21 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 934533F694; Wed, 27 Mar 2024 05:20:45 -0700 (PDT) Date: Wed, 27 Mar 2024 12:20:39 +0000 From: Cristian Marussi To: Dan Carpenter Cc: "Peng Fan (OSS)" , Sudeep Holla , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, Peng Fan , Oleksii Moisieiev Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Message-ID: References: <20240323-pinctrl-scmi-v6-0-a895243257c0@nxp.com> <20240323-pinctrl-scmi-v6-3-a895243257c0@nxp.com> <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240327_052049_923607_9635E518 X-CRM114-Status: GOOD ( 25.00 ) 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, Mar 27, 2024 at 01:46:11PM +0300, Dan Carpenter wrote: > Looks really nice. Just a few small comments below. > Hi, I aa having a look at this today (and try to retest it), just a quick remark down below... > On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote: > > + > > +struct scmi_msg_func_set { > > + __le32 identifier; > > + __le32 function_id; > > + __le32 flags; > > +}; > > This scmi_msg_func_set struct is unused. Delete. > > > +static void > > +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index, > > + const void *priv) > > +{ > > + struct scmi_msg_settings_get *msg = message; > > + const struct scmi_settings_get_ipriv *p = priv; > > + u32 attributes; > > + > > + attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) | > > + FIELD_PREP(SELECTOR_MASK, p->type); > > + > > + if (p->flag == 1) > > + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index); > > + else if (!p->flag) > > This is a nit-pick but could you change these !p->flag conditions to > p->flag == 0? It's a number zero, not a bool. > > > + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p->config_types[0]); > > + > > + msg->attributes = cpu_to_le32(attributes); > > + msg->identifier = cpu_to_le32(p->selector); > > +} > > + > > +static int > > +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st, > > + const void *response, void *priv) > > +{ > > + const struct scmi_resp_settings_get *r = response; > > + struct scmi_settings_get_ipriv *p = priv; > > + > > + if (p->flag == 1) { > > + st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0)); > > + st->num_remaining = le32_get_bits(r->num_configs, > > + GENMASK(31, 24)); > > + } else { > > + st->num_returned = 1; > > + st->num_remaining = 0; > > + } > > + > > + return 0; > > +} > > + > > +static int > > +iter_pinctrl_settings_get_process_response(const struct scmi_protocol_handle *ph, > > + const void *response, > > + struct scmi_iterator_state *st, > > + void *priv) > > +{ > > + const struct scmi_resp_settings_get *r = response; > > + struct scmi_settings_get_ipriv *p = priv; > > + > > + if (!p->flag) { > > > if (p->flag == 0) { > > > + if (p->config_types[0] != > > + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0))) > > + return -EINVAL; > > + } else if (p->flag == 1) { > > + p->config_types[st->desc_index + st->loop_idx] = > > + le32_get_bits(r->configs[st->loop_idx * 2], > > + GENMASK(7, 0)); > > + } else if (p->flag == 2) { > > + return 0; > > + } > > + > > + p->config_values[st->desc_index + st->loop_idx] = > > + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]); > > + > > + return 0; > > +} > > + > > +static int > > +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32 selector, > > + enum scmi_pinctrl_selector_type type, > > + enum scmi_pinctrl_conf_type config_type, > > + u32 *config_value) > > +{ > > + int ret; > > + void *iter; > > + struct scmi_iterator_ops ops = { > > + .prepare_message = iter_pinctrl_settings_get_prepare_message, > > + .update_state = iter_pinctrl_settings_get_update_state, > > + .process_response = iter_pinctrl_settings_get_process_response, > > + }; > > + struct scmi_settings_get_ipriv ipriv = { > > + .selector = selector, > > + .type = type, > > + .flag = 0, > > ->flag should be 0-2. > The .flag in this priv structure is for 'configuring' the iterators in the SCMI core to parse a multi-part response, so (looking at how the iterators functs are implemented above) setting it here to zero means issuing a SETTINGS_GET with attributes.config_flag[19:18] == 0, that in turn means requesting just a single config_value to be read... ...if you want to support the other 'flavours' of SETTINGS_GET (multiple configs & selected_func) you will have to extend the signature of this function to optionally select to readback multiple configs (and to allow the return of such multiple config_values) and/or optionally request to return the selected function.... ...or maybe add distinct wrapper protocol_ops just for these flavours... Anyway, till now in this series it was avoided to add such 'flavours' support (e.g. for multiple configs) since there are no users for the multi-config and function selected in the pinctrl driver...so no way to test.. Will the Linux GPIO driver need these ? Should we delay anyway the addition of the support of such variants of SETTING_GET for when a real user like GPIO driveer appears ? ...anyway @Peng please add a comment somewhere explaining how p->flag is used to configure the type of SETTINGS_GET Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel