From: Cristian Marussi <cristian.marussi@arm.com> To: Dan Carpenter <dan.carpenter@linaro.org> Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>, Sudeep Holla <sudeep.holla@arm.com>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, Peng Fan <peng.fan@nxp.com>, Oleksii Moisieiev <oleksii_moisieiev@epam.com> Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Date: Wed, 27 Mar 2024 12:20:39 +0000 [thread overview] Message-ID: <ZgQPF_jT07hudU1H@pluto> (raw) In-Reply-To: <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain> 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
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: Dan Carpenter <dan.carpenter@linaro.org> Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>, Sudeep Holla <sudeep.holla@arm.com>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, Peng Fan <peng.fan@nxp.com>, Oleksii Moisieiev <oleksii_moisieiev@epam.com> Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Date: Wed, 27 Mar 2024 12:20:39 +0000 [thread overview] Message-ID: <ZgQPF_jT07hudU1H@pluto> (raw) In-Reply-To: <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain> 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
next prev parent reply other threads:[~2024-03-27 12:20 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-23 12:15 [PATCH v6 0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Peng Fan (OSS) 2024-03-23 12:15 ` Peng Fan (OSS) 2024-03-23 12:15 ` [PATCH v6 1/4] firmware: arm_scmi: introduce helper get_max_msg_size Peng Fan (OSS) 2024-03-23 12:15 ` Peng Fan (OSS) 2024-03-23 12:15 ` [PATCH v6 2/4] dt-bindings: firmware: arm,scmi: support pinctrl protocol Peng Fan (OSS) 2024-03-23 12:15 ` Peng Fan (OSS) 2024-03-23 12:15 ` [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Peng Fan (OSS) 2024-03-23 12:15 ` Peng Fan (OSS) 2024-03-27 10:46 ` Dan Carpenter 2024-03-27 10:46 ` Dan Carpenter 2024-03-27 12:20 ` Cristian Marussi [this message] 2024-03-27 12:20 ` Cristian Marussi 2024-03-31 12:47 ` Peng Fan 2024-03-31 12:47 ` Peng Fan 2024-03-28 15:47 ` Cristian Marussi 2024-03-28 15:47 ` Cristian Marussi 2024-03-31 13:28 ` Peng Fan 2024-03-31 13:28 ` Peng Fan 2024-03-29 19:00 ` Andy Shevchenko 2024-03-29 19:00 ` Andy Shevchenko 2024-03-31 13:44 ` Peng Fan 2024-03-31 13:44 ` Peng Fan 2024-04-02 7:48 ` Cristian Marussi 2024-04-02 7:48 ` Cristian Marussi 2024-04-02 13:06 ` Andy Shevchenko 2024-04-02 13:06 ` Andy Shevchenko 2024-04-02 14:01 ` Peng Fan 2024-04-02 14:01 ` Peng Fan 2024-04-02 14:35 ` Peng Fan 2024-04-02 14:35 ` Peng Fan 2024-04-02 15:58 ` Cristian Marussi 2024-04-02 15:58 ` Cristian Marussi 2024-04-02 16:39 ` Andy Shevchenko 2024-04-02 16:39 ` Andy Shevchenko 2024-04-03 8:06 ` Cristian Marussi 2024-04-03 8:06 ` Cristian Marussi 2024-04-03 8:44 ` Andy Shevchenko 2024-04-03 8:44 ` Andy Shevchenko 2024-03-23 12:15 ` [PATCH v6 4/4] pinctrl: Implementation of the generic scmi-pinctrl driver Peng Fan (OSS) 2024-03-23 12:15 ` Peng Fan (OSS) 2024-03-27 11:20 ` Dan Carpenter 2024-03-27 11:20 ` Dan Carpenter 2024-03-28 16:46 ` Cristian Marussi 2024-03-28 16:46 ` Cristian Marussi 2024-03-29 19:10 ` Andy Shevchenko 2024-03-29 19:10 ` Andy Shevchenko 2024-03-28 16:48 ` [PATCH v6 0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Cristian Marussi 2024-03-28 16:48 ` Cristian Marussi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZgQPF_jT07hudU1H@pluto \ --to=cristian.marussi@arm.com \ --cc=conor+dt@kernel.org \ --cc=dan.carpenter@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=oleksii_moisieiev@epam.com \ --cc=peng.fan@nxp.com \ --cc=peng.fan@oss.nxp.com \ --cc=robh@kernel.org \ --cc=sudeep.holla@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.