[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240216170149.040ff86b@jic23-huawei>
Date: Fri, 16 Feb 2024 17:01:49 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Mike Looijmans <mike.looijmans@...ic.nl>
Cc: devicetree@...r.kernel.org, linux-iio@...r.kernel.org, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Arnd Bergmann <arnd@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>, Liam Beguin <liambeguin@...il.com>,
Liam Girdwood <lgirdwood@...il.com>, Maksim Kiselev
<bigunclemax@...il.com>, Marcus Folkesson <marcus.folkesson@...il.com>,
Marius Cristea <marius.cristea@...rochip.com>, Mark Brown
<broonie@...nel.org>, Niklas Schnelle <schnelle@...ux.ibm.com>, Okan Sahin
<okan.sahin@...log.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] iio: adc: ti-ads1298: Add driver
On Fri, 16 Feb 2024 16:30:20 +0100
Mike Looijmans <mike.looijmans@...ic.nl> wrote:
> Skeleton driver for the TI ADS1298 medical ADC. This device is
> typically used for ECG and similar measurements. Supports data
> acquisition at configurable scale and sampling frequency.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
>
> ---
>
> Changes in v5:
> Derive the name from the chip ID register
> Fail probe if the ID is unknown
This is a fun corner when it comes to DT bindings where we may
have fallback compatibles for parts introduced in the future.
For those we are supposed to ignore ID registers and just
assume they are correct (in IIO I tends to suggest we print
a message to say we are carrying on despite not recognising the
ID) We could go half way here and assume the channel count
can always be gotten from the register, but relax the family bit
to allow families that aren't yet 'born'.
If we don't assume channel count, we would need to add explicit
entries to the ID tables for each of the device supported.
Anyhow, I have no problem leaving that as a problem for another day.
> Interpret the number of channels (only tested the "8")
The way you've done this will not work if you want to add a timestamp
(which is tricky in this device anyway) but for now it is fine.
I tweaked the order in kconfig and Makefile whilst applying.
The relevant sections aren't in alphanumeric order as currently
the TI parts with longer names come later. Having said that this
fits better after ADS1100 than where you have it so I've moved
it up to there.
However...
CHECK drivers/iio/adc/ti-ads1298.c
drivers/iio/adc/ti-ads1298.c:424:13: warning: context imbalance in 'ads1298_rdata_unmark_busy' - wrong count at exit
drivers/iio/adc/ti-ads1298.c:465:9: warning: context imbalance in 'ads1298_rdata_release_busy_or_restart' - wrong count at exit
drivers/iio/adc/ti-ads1298.c:531:9: warning: context imbalance in 'ads1298_interrupt' - wrong count at exit
MODPOST Module.symvers
sparse isn't happy (and I upgraded it to make sure I had anything new for guard() etc)
I think it is the missing context tracking referred to here:
https://lore.kernel.org/linux-sparse/Zag2fYsyJDtDR7a6@google.com/
Anyhow, looks like false positives so applied to the togreg branch of iio.git
but first pushed out as testing to let 0-day take a look.
Thanks,
Jonathan
Powered by blists - more mailing lists