All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matteo Martelli <matteomartelli3@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Peter Rosin <peda@axentia.se>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: iio-mux: kzalloc instead of devm_kzalloc to ensure page alignment
Date: Mon, 09 Dec 2024 11:39:55 +0100	[thread overview]
Message-ID: <97fd092da34bcdcf0a7f79c6079a04ce@gmail.com> (raw)
In-Reply-To: <20241208181531.47997ab4@jic23-huawei>

On Sun, 8 Dec 2024 18:15:31 +0000, Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon, 02 Dec 2024 16:11:08 +0100
> Matteo Martelli <matteomartelli3@gmail.com> wrote:
> 
> > During channel configuration, the iio-mux driver allocates a page with
> > devm_kzalloc(PAGE_SIZE) to read channel ext_info. However, the resulting
> > buffer points to an offset of the page due to the devres header sitting
> > at the beginning of the allocated area. This leads to failure in the
> > provider driver when sysfs_emit* helpers are used to format the ext_info
> > attributes.
> > 
> > Switch to plain kzalloc version. The devres version is not strictly
> > necessary as the buffer is only accessed during the channel
> > configuration phase. Rely on __free cleanup to deallocate the buffer.
> > Also, move the ext_info handling into a new function to have the page
> > buffer definition and assignment in one statement as suggested by
> > cleanup documentation.
> > 
> > Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com>
> This seems fine to me, but the diff ended up a bit complex, so I'd like
> Peter to take a look as well before I apply it.

For a simpler diff I could go for devm_get_free_pages()+devm_free_pages(),
but since devres doesn't seem necessary in this case, I think this patch
provides a cleaner solution at the end.

> 
> Do you have a board that is hitting this?  If so, a fixes tag is definitely
> appropriate. I think it is probably appropriate even it not.

I am not sure if any existing board is affected as I encountered this
issue while experimenting with consumer drivers, thus using a custom DT
on top of sun50i-a64-pine64.dts just for testing. The following DT files
might be affected but only if the iio channel controlled by the iio_mux
multiplexer owns an ext_info attribute which is also exposed on sysfs.

$ grep -Rl 'io-channel-mux' arch
arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtjade.dts
arch/arm/boot/dts/microchip/at91-tse850-3.dts
arch/arm/boot/dts/microchip/at91-natte.dtsi
arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353x.dtsi
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts
arch/arm64/boot/dts/allwinner/sun50i-h700-anbernic-rg35xx-h.dtb
arch/arm64/boot/dts/allwinner/sun50i-h700-anbernic-rg35xx-h.dts

I am also not sure what would be the reference commit for the Fixes tag.
The related ext_info attributes handling was introduced in the first
commit of the iio_mux implementation. If that applies, following the
corresponding Fixes tag.

Fixes: 7ba9df54b091 ("iio: multiplexer: new iio category and iio-mux driver")

> 
> Jonathan
> 

Best regards,
Matteo
> > ---
> >  drivers/iio/multiplexer/iio-mux.c | 84 +++++++++++++++++++++------------------
> >  1 file changed, 46 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/iio/multiplexer/iio-mux.c b/drivers/iio/multiplexer/iio-mux.c
> > index 2953403bef53bbe47a97a8ab1c475ed88d7f86d2..c309d991490c63ba4299f1cda7102f10dcf54982 100644
> > --- a/drivers/iio/multiplexer/iio-mux.c
> > +++ b/drivers/iio/multiplexer/iio-mux.c
> > @@ -7,6 +7,7 @@
> >   * Author: Peter Rosin <peda@axentia.se>
> >   */
> >  
> > +#include <linux/cleanup.h>
> >  #include <linux/err.h>
> >  #include <linux/iio/consumer.h>
> >  #include <linux/iio/iio.h>
> > @@ -237,49 +238,18 @@ static ssize_t mux_write_ext_info(struct iio_dev *indio_dev, uintptr_t private,
> >  	return ret;
> >  }
> >  
> > -static int mux_configure_channel(struct device *dev, struct mux *mux,
> > -				 u32 state, const char *label, int idx)
> > +static int mux_configure_chan_ext_info(struct device *dev, struct mux *mux,
> > +				       int idx, int num_ext_info)
> >  {
> >  	struct mux_child *child = &mux->child[idx];
> > -	struct iio_chan_spec *chan = &mux->chan[idx];
> >  	struct iio_chan_spec const *pchan = mux->parent->channel;
> > -	char *page = NULL;
> > -	int num_ext_info;
> >  	int i;
> >  	int ret;
> >  
> > -	chan->indexed = 1;
> > -	chan->output = pchan->output;
> > -	chan->datasheet_name = label;
> > -	chan->ext_info = mux->ext_info;
> > -
> > -	ret = iio_get_channel_type(mux->parent, &chan->type);
> > -	if (ret < 0) {
> > -		dev_err(dev, "failed to get parent channel type\n");
> > -		return ret;
> > -	}
> > -
> > -	if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> > -		chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
> > -	if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
> > -		chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
> > -
> > -	if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
> > -		chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
> > -
> > -	if (state >= mux_control_states(mux->control)) {
> > -		dev_err(dev, "too many channels\n");
> > -		return -EINVAL;
> > -	}
> > -
> > -	chan->channel = state;
> > +	char *page __free(kfree) = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > +	if (!page)
> > +		return -ENOMEM;
> >  
> > -	num_ext_info = iio_get_channel_ext_info_count(mux->parent);
> > -	if (num_ext_info) {
> > -		page = devm_kzalloc(dev, PAGE_SIZE, GFP_KERNEL);
> > -		if (!page)
> > -			return -ENOMEM;
> > -	}
> >  	child->ext_info_cache = devm_kcalloc(dev,
> >  					     num_ext_info,
> >  					     sizeof(*child->ext_info_cache),
> > @@ -318,8 +288,46 @@ static int mux_configure_channel(struct device *dev, struct mux *mux,
> >  		child->ext_info_cache[i].size = ret;
> >  	}
> >  
> > -	if (page)
> > -		devm_kfree(dev, page);
> > +	return 0;
> > +}
> > +
> > +static int mux_configure_channel(struct device *dev, struct mux *mux, u32 state,
> > +				 const char *label, int idx)
> > +{
> > +	struct iio_chan_spec *chan = &mux->chan[idx];
> > +	struct iio_chan_spec const *pchan = mux->parent->channel;
> > +	int num_ext_info;
> > +	int ret;
> > +
> > +	chan->indexed = 1;
> > +	chan->output = pchan->output;
> > +	chan->datasheet_name = label;
> > +	chan->ext_info = mux->ext_info;
> > +
> > +	ret = iio_get_channel_type(mux->parent, &chan->type);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to get parent channel type\n");
> > +		return ret;
> > +	}
> > +
> > +	if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> > +		chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
> > +	if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
> > +		chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
> > +
> > +	if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
> > +		chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
> > +
> > +	if (state >= mux_control_states(mux->control)) {
> > +		dev_err(dev, "too many channels\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	chan->channel = state;
> > +
> > +	num_ext_info = iio_get_channel_ext_info_count(mux->parent);
> > +	if (num_ext_info)
> > +		return mux_configure_chan_ext_info(dev, mux, idx, num_ext_info);
> >  
> >  	return 0;
> >  }
> > 
> 


  reply	other threads:[~2024-12-09 10:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02 15:11 [PATCH 0/2] iio: consumers: ensure read buffers for labels and ext_info are page aligned Matteo Martelli
2024-12-02 15:11 ` [PATCH 1/2] " Matteo Martelli
2024-12-08 18:16   ` Jonathan Cameron
2024-12-02 15:11 ` [PATCH 2/2] iio: iio-mux: kzalloc instead of devm_kzalloc to ensure page alignment Matteo Martelli
2024-12-08 18:15   ` Jonathan Cameron
2024-12-09 10:39     ` Matteo Martelli [this message]
2024-12-11 18:17       ` Jonathan Cameron
2025-01-04 14:49         ` Jonathan Cameron
2025-01-12 16:24       ` Andy Shevchenko
2025-01-12 16:35         ` Jonathan Cameron
2024-12-17 16:14   ` David Lechner

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=97fd092da34bcdcf0a7f79c6079a04ce@gmail.com \
    --to=matteomartelli3@gmail.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    /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: link
Be 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.