devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Flaviu Nistor" <flaviu.nistor@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 2/2] iio: adc: ti-ads1015: Add support for label
Date: Wed, 02 Sep 2026 17:40:03 +0000	[thread overview]
Message-ID: <20260902174004.1A5E91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902172230.5234-2-flaviu.nistor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `ads1015_read_label()` function passes a potentially NULL pointer to `sysfs_emit()`, causing userspace to read `"(null)\n"` for unconfigured channels.
--

commit 9084b6f4b1c391e596d3456f4a84598bb430a6e6
Author: Flaviu Nistor <flaviu.nistor@gmail.com>
Subject: iio: adc: ti-ads1015: Add support for label

Add support for label sysfs attribute similar to other adc devices. This is
particularly useful because the label can match the schematic signal name,
identifying channel voltages easier if label is defined via device tree.

Link: https://lore.kernel.org/all/20260901184302.8127-2-flaviu.nistor@gmail.com/

> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> index 0fbfa4e499aa8..8be1f0c32ca9d 100644
> --- a/drivers/iio/adc/ti-ads1015.c
> +++ b/drivers/iio/adc/ti-ads1015.c
[ ... ]
> @@ -586,6 +587,15 @@ static int ads1015_read_raw(struct iio_dev *indio_dev,
>  	}
>  }
>  
> +static int ads1015_read_label(struct iio_dev *indio_dev,
> +			      struct iio_chan_spec const *chan, char *label)
> +{
> +	struct ads1015_data *data = iio_priv(indio_dev);
> +	const char *name = data->channel_data[chan->address].label;
> +
> +	return sysfs_emit(label, "%s\n", name);

[Severity: Medium]
Will this return "(null)\n" to userspace for channels without a configured
label?

If a channel is not explicitly defined in the firmware nodes, or if the driver
falls back to the default configuration via ads1015_get_channels_config(),
the label field will remain NULL. Passing a NULL pointer to sysfs_emit()
results in an incorrect literal "(null)\n" output at the UAPI boundary.

> +}
> +
>  static int ads1015_write_raw(struct iio_dev *indio_dev,
>  			     struct iio_chan_spec const *chan, int val,
>  			     int val2, long mask)
[ ... ]
> @@ -897,6 +911,17 @@ static int ads1015_client_get_channels_config(struct i2c_client *client)
>  			}
>  		}
>  
> +		if (fwnode_property_present(node, "label")) {
> +			ret = fwnode_property_read_string(node, "label", &label);
> +			if (ret) {
> +				dev_err(dev, "invalid label on %pfw\n", node);
> +				return ret;
> +			}
> +			data->channel_data[channel].label = label;
> +		} else {
> +			data->channel_data[channel].label = "";
> +		}
> +

[Severity: Medium]
Are there cases where some channels might be skipped in this loop?

Since this initialization is contained within the child node iteration loop,
it only covers channels that are explicitly defined in the firmware nodes.
Channels omitted from the device tree will remain zero-initialized, leaving
their label field as NULL.

>  		data->channel_data[channel].pga = pga;
>  		data->channel_data[channel].data_rate = data_rate;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902172230.5234-1-flaviu.nistor@gmail.com?part=2

  reply	other threads:[~2026-09-02 17:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 17:22 [PATCH v2 1/2] dt-bindings: iio: adc: ti,ads1015: Add label property Flaviu Nistor
2026-09-02 17:22 ` [PATCH v2 2/2] iio: adc: ti-ads1015: Add support for label Flaviu Nistor
2026-09-02 17:40   ` sashiko-bot [this message]
2026-09-02 18:37   ` David Lechner
2026-09-03  6:18     ` Andy Shevchenko
2026-09-03 15:16       ` Flaviu Nistor
2026-09-03 15:28         ` David Lechner
2026-09-03 19:03         ` Andy Shevchenko
2026-09-02 18:31 ` [PATCH v2 1/2] dt-bindings: iio: adc: ti,ads1015: Add label property David Lechner
2026-09-03 15:19   ` Flaviu Nistor
2026-09-03 15:30     ` 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=20260902174004.1A5E91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=flaviu.nistor@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).