linux-kernel - Re: [PATCH 2/2] iio: pressure: add Honeywell ABP2 driver

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: <20251206201349.12d6c5b5@jic23-huawei>
Date: Sat, 6 Dec 2025 20:13:49 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Petre Rodan <petre.rodan@...dimension.ro>, David Lechner
 <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: pressure: add Honeywell ABP2 driver

> ...
> 
> > +int abp2_common_probe(struct device *dev, const struct abp2_ops *ops, int irq)
> > +{
> > +	int ret;
> > +	struct abp2_data *data;
> > +	struct iio_dev *indio_dev;
> > +	const char *triplet;
> > +	s64 tmp;
> > +
> > +	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> > +	if (!indio_dev)
> > +		return -ENOMEM;
> > +
> > +	data = iio_priv(indio_dev);
> > +	data->dev = dev;
> > +	data->ops = ops;
> > +	data->irq = irq;
> > +
> > +	init_completion(&data->completion);
> > +
> > +	indio_dev->name = "abp2030pa";
> > +	indio_dev->info = &abp2_info;
> > +	indio_dev->channels = abp2_channels;
> > +	indio_dev->num_channels = ARRAY_SIZE(abp2_channels);  
> 
> > +	indio_dev->modes = INDIO_DIRECT_MODE;  
> 
> Doesn't IIO core take care of this?
Not currently.  We should revisit if we this ever actually proved
useful to set.  It dates back to very early in IIO where I assumed
we would want to differential devices that only do buffered capture from
those that can do that and single shot. I'm not sure we actually have
any in that category though :(

So maybe we can justify dropping this across all drivers at somepoint
or as you say just set it as a default value.

Jonathan