linux-kernel - Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZgQPF_jT07hudU1H@pluto>
Date: Wed, 27 Mar 2024 12:20:39 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: "Peng Fan (OSS)" <peng.fan@....nxp.com>,
	Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
	Peng Fan <peng.fan@....com>,
	Oleksii Moisieiev <oleksii_moisieiev@...m.com>
Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support

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