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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Aug 2023 14:34:55 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        Rob Herring <robh+dt@...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-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v4 3/4] pinctrl: Implementation of the generic
 scmi-pinctrl driver

On Wed, Aug 23, 2023 at 01:13:12PM +0900, AKASHI Takahiro wrote:
> Hi Oleksii,
> 

Hi AKASHI, Oleksii,

> On Tue, Aug 08, 2023 at 06:25:35PM +0000, Oleksii Moisieiev wrote:
> > scmi-pinctrl driver implements pinctrl driver interface and using
> > SCMI protocol to redirect messages from pinctrl subsystem SDK to
> > SCMI platform firmware, which does the changes in HW.
> > 
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@...m.com>

[snip]

> > +static int pinctrl_scmi_pinconf_get(struct pinctrl_dev *pctldev, unsigned int _pin,
> > +				    unsigned long *config)
> > +{
> > +	int ret;
> > +	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
> > +	enum pin_config_param config_type;
> > +	unsigned long config_value;
> > +
> > +	if (!config)
> > +		return -EINVAL;
> > +
> > +	config_type = pinconf_to_config_param(*config);
> > +
> > +	ret = pinctrl_ops->config_get(pmx->ph, _pin, PIN_TYPE, config_type, &config_value);
> > +	if (ret)
> > +		return ret;
> > +
> > +	*config = pinconf_to_config_packed(config_type, config_value);
> > +
> > +	return 0;
> > +}
> > +
> > +static int pinctrl_scmi_pinconf_set(struct pinctrl_dev *pctldev,
> > +				    unsigned int _pin,
> > +				    unsigned long *configs,
> > +				    unsigned int num_configs)
> > +{
> > +	int i, ret;
> > +	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
> > +	enum pin_config_param config_type;
> > +	unsigned long config_value;
> > +
> > +	if (!configs || num_configs == 0)
> > +		return -EINVAL;
> > +
> > +	for (i = 0; i < num_configs; i++) {
> > +		config_type = pinconf_to_config_param(configs[i]);
> > +		config_value = pinconf_to_config_argument(configs[i]);
> 
> The generic pinconf parameters defined as "enum pin_config_param"
> do not exactly match with a set of SCMI's configuration types defined
> in Table 23 in the section 4.11.2.6 "PINCTRL_CONFIG_GET".
> pinconf_to_config_param() simply masks the lowest 8 bits of the input
> value, but doesn't convert anything.

Indeed the SCMI Types table and the Linux Pinctrl subsystem types are
similar but not really the same; some kind of conversion/mapping will be
needed.

Some trivial conversion layer will be needed also in order to address
here any of the possible future changes in the Linux pinctrl subsystem
definitions without having to change the SCMI server side
(that typically is fw...and that anyway is bound to the SCMI spec)

Thanks,
Cristian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ