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]
Date:   Tue, 18 May 2021 10:57:31 +0200 (CEST)
From:   Dario Binacchi <dariobin@...ero.it>
To:     Tony Lindgren <tony@...mide.com>
Cc:     linux-kernel@...r.kernel.org,
        Haojian Zhuang <haojian.zhuang@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-gpio@...r.kernel.org,
        linux-omap@...r.kernel.org
Subject: Re: [PATCH v2 2/2] pinctrl: single: set pinmux from pins debug file

Hi Tony,

> Il 18/05/2021 08:05 Tony Lindgren <tony@...mide.com> ha scritto:
> 
>  
> Hi,
> 
> I noticed few more things I started to wonder about after
> looking at this again.
> 
> * Dario Binacchi <dariobin@...ero.it> [210517 20:00]:
> > +static int pcs_pin_dbg_set(struct pinctrl_dev *pctldev, unsigned int pin,
> > +			   char *buf)
> > +{
> > +	struct pcs_device *pcs;
> > +	unsigned int val, mux_bytes;
> > +
> > +	buf = skip_spaces(buf);
> > +	if (kstrtouint(buf, 0, &val))
> > +		return -EINVAL;
> > +
> > +	pcs = pinctrl_dev_get_drvdata(pctldev);
> > +
> > +	mux_bytes = pcs->width / BITS_PER_BYTE;
> > +	pcs->write(val, pcs->base + pin * mux_bytes);
> > +	return 0;
> > +}
> 
> Since you're adding a new interface, how about pass unsigned
> int val instead of char *buf?

I thought about passing char *buf because it seemed more generic 
to me. As the output of pin_dbg_show() depends on the platform 
driver, perhaps pin_dbg_set() may need driver-dependent data.
Is it possible that only the value to be set in the register 
(unsigned int) is required?

> 
> >  static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
> >  				struct pinctrl_map *map, unsigned num_maps)
> >  {
> > @@ -331,6 +348,9 @@ static const struct pinctrl_ops pcs_pinctrl_ops = {
> >  	.get_group_name = pinctrl_generic_get_group_name,
> >  	.get_group_pins = pinctrl_generic_get_group_pins,
> >  	.pin_dbg_show = pcs_pin_dbg_show,
> > +#if IS_ENABLED(CONFIG_DEVMEM)
> > +	.pin_dbg_set = pcs_pin_dbg_set,
> > +#endif
> >  	.dt_node_to_map = pcs_dt_node_to_map,
> >  	.dt_free_map = pcs_dt_free_map,
> >  };
> 
> It might be better to always have the .pin_dbg_set around to
> avoid the IS_ENABLED(CONFIG_DEVMEM).

Ok, I'll remove the CONFIG_DEVMEM dependency

> 
> Does the new interface need something under Documentation too?

Yes, the description of `pins` in Documentation/driver-api/pin-control.rst 
needs to be updated. I'll add another patch to the series.

Thanks and regards,
Dario

> 
> Regards,
> 
> Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ