linux-kernel - Re: [PATCH] iio: position: iqs624: remove usage of iio_priv_to

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: <20200523015340.GA2690@labundy.com>
Date:   Fri, 22 May 2020 20:53:40 -0500
From:   Jeff LaBundy <jeff@...undy.com>
To:     Alexandru Ardelean <alexandru.ardelean@...log.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        jic23@...nel.org
Subject: Re: [PATCH] iio: position: iqs624: remove usage of iio_priv_to_dev()

Hi Alexandru,

On Fri, May 22, 2020 at 09:53:22AM +0300, Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. That's a bit
> uncertain at this point. The reason is that we will hide some of the
> members of the iio_dev structure (to prevent drivers from accessing them
> directly), and that will also mean hiding the implementation of the
> iio_priv_to_dev() helper inside the IIO core.
> 
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
> 
> For this driver, removing iio_priv_to_dev() also means keeping a reference
> on the state struct.
> 
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@...log.com>
> ---
>  drivers/iio/position/iqs624-pos.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

As a customer of iio, I find it handy that there is an "inverse" to iio_priv.
In this particular case it saves the container iio_dev from storing a pointer
to itself.

That being said, this patch is perfectly fine and I have no objection if this
is the route you and Jonathan opt to take. And so:

Acked-by: Jeff LaBundy <jeff@...undy.com>

> 
> diff --git a/drivers/iio/position/iqs624-pos.c b/drivers/iio/position/iqs624-pos.c
> index 77096c31c2ba..520dafbdc48f 100644
> --- a/drivers/iio/position/iqs624-pos.c
> +++ b/drivers/iio/position/iqs624-pos.c
> @@ -23,6 +23,7 @@
>  
>  struct iqs624_pos_private {
>  	struct iqs62x_core *iqs62x;
> +	struct iio_dev *indio_dev;
>  	struct notifier_block notifier;
>  	struct mutex lock;
>  	bool angle_en;
> @@ -59,7 +60,7 @@ static int iqs624_pos_notifier(struct notifier_block *notifier,
>  
>  	iqs624_pos = container_of(notifier, struct iqs624_pos_private,
>  				  notifier);
> -	indio_dev = iio_priv_to_dev(iqs624_pos);
> +	indio_dev = iqs624_pos->indio_dev;
>  	timestamp = iio_get_time_ns(indio_dev);
>  
>  	iqs62x = iqs624_pos->iqs62x;
> @@ -98,7 +99,7 @@ static int iqs624_pos_notifier(struct notifier_block *notifier,
>  static void iqs624_pos_notifier_unregister(void *context)
>  {
>  	struct iqs624_pos_private *iqs624_pos = context;
> -	struct iio_dev *indio_dev = iio_priv_to_dev(iqs624_pos);
> +	struct iio_dev *indio_dev = iqs624_pos->indio_dev;
>  	int ret;
>  
>  	ret = blocking_notifier_chain_unregister(&iqs624_pos->iqs62x->nh,
> @@ -243,6 +244,7 @@ static int iqs624_pos_probe(struct platform_device *pdev)
>  
>  	iqs624_pos = iio_priv(indio_dev);
>  	iqs624_pos->iqs62x = iqs62x;
> +	iqs624_pos->indio_dev = indio_dev;
>  
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  	indio_dev->dev.parent = &pdev->dev;
> -- 
> 2.25.1
> 

Kind regards,
Jeff LaBundy