From: Aldo Conte <aldocontelk@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
shuah@kernel.org, joshua.crofts1@gmail.com,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH v3 8/8] iio: tcs3472: implement wait time and sampling frequency
Date: Tue, 26 May 2026 17:10:14 +0200 [thread overview]
Message-ID: <5557d9b9-9869-45ce-9c28-cb24cdb03cda@gmail.com> (raw)
In-Reply-To: <20260526141159.267d9623@jic23-huawei>
On 26/05/26 15:11, Jonathan Cameron wrote:
> On Fri, 22 May 2026 14:34:19 +0200
> Aldo Conte <aldocontelk@gmail.com> wrote:
>
>> The TCS3472 has a wait state controlled by the WEN bit in the ENABLE
>> register and the WAIT register, with an additional WLONG bit in CONFIG
>> that if set multiplies the wait step by 12. The driver previously
>> defined TCS3472_WTIME but never used it leaving the TODO comment on
>> the top of the source file.
>>
>> Implement control of the wait time through IIO_CHAN_INFO_SAMP_FREQ:
>>
>> - Reading sampling_frequency returns the chip's current cycle time,
>> computed as the sum of ATIME, the fixed RGBC initialization time
>> and the wait time (which depends on WEN and WLONG).
>>
>> - Writing sampling_frequency programs WTIME so that the resulting
>> cycle period approximates the requested frequency. If the
>> requested frequency cannot be reached with any
>> non-zero wait time, WEN is disabled and the chip runs
>> back-to-back conversions at the maximum rate allowed by ATIME.
>> If the requested period exceeds the maximum WTIME range, WLONG
>> is enabled to extend the wait step from 2.4 ms to 28.8 ms.
>>
>> - The user's last requested frequency is stored in the driver's
>> private data so that subsequent changes to integration_time
>> recompute WTIME and preserve the requested sampling rate as
>> closely as possible.
>>
>> Add TCS3472_ENABLE_WEN, TCS3472_ENABLE_RUN and TCS3472_CONFIG_WLONG
>> bit definitions. TCS3472_ENABLE_RUN bundles the bits
>> (AEN | PON | WEN) that are simultaneously set when the chip is in
>> running state and cleared during powerdown, and is used by
>> tcs3472_probe(), tcs3472_powerdown().
>>
>> In tcs3472_resume(), only PON and AEN are re-asserted while WEN is
>> preserved from data->enable.
>>
>> Remove the "TODO: wait time" comment at the top of the file.
> Hi Aldo,
>
> Please look at Sashiko's comments on this particular patch
> (the others are about an issue that has nothing to do with your series)
>
> https://sashiko.dev/#/patchset/20260522123420.45495-1-aldocontelk%40gmail.com
>
> The suggestion is that you need to make the timeout in
> tcs3472_req_data() longer given with these settings the capture may
> take a lot longer than previously.
>
> There is some other general good practice stuff in there. For example:
>> + data->enable &= ~TCS3472_ENABLE_WEN;
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + TCS3472_ENABLE,
>> + data->enable);
>
> if you were to use a local variable to do the masking on enable
>
> enable = data->enable & ~TCS3472_ENABLE_WEN;
> ret = i2c_smbus_write_byte_data(data->client,..., enable);
> if (ret)
> return ret;
>
> data->enable = enable;
>
> You'd ensure that 'to best effort' the cached value is not updated
> if the write fails. The approx (possibly correct) arguement is that
> any failure in i2c_smbus_write_byte_data() is more likely to have
> left the original state alone than successfully written the new one.
> Or more generally the principle that in ideal world any call that fails
> has no side effects.
>
> Anyhow, take a look at all the feedback. If you disagree with any of
> it feel free to add a note to the change log of the next version.
>
>
> Ah. I've just noticed that as part of this you did make the change
> I suggested in patch 3. Oops - I should have checked. It is fine
> in here.
>
> I didn't crop so that you'd have full context visible. A few specific
> cases and comments inline.
>
> Note I've picked up patches 1-7 so it's just this one that needs
> revisions for v4.
>
> thanks,
>
> Jonathan
>
>
>>
>> Signed-off-by: Aldo Conte <aldocontelk@gmail.com>
>> ---
>> v3:
>> - Drop Suggested-by: Andy (inappropriate tag).
>> - TCS3472_ENABLE_RUN: new style.
>> - cycle_us: use div64_u64().
>> - cycle_us: cast val to u64 for 32-bit safety.
>> - wait_us: keep s64; added comment explaining the range bounds.
>> - Use 'if (ret)' instead of 'if (ret < 0)' after i2c writes.
>> - New helper tcs3472_cycle_to_freq() deduplicates val/val2 logic.
>> - !! -> ? 1 : 0 in probe.
>> - Fix tcs3472_resume(): preserve WEN from data->enable instead of
>> forcing TCS3472_ENABLE_RUN.
>>
>> drivers/iio/light/tcs3472.c | 245 +++++++++++++++++++++++++++++++++---
>> 1 file changed, 227 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
>> index 1f597ca93697..81549d7eba35 100644
>> --- a/drivers/iio/light/tcs3472.c
>> +++ b/drivers/iio/light/tcs3472.c
>> @@ -9,8 +9,6 @@
>> * TCS34727)
>> *
>> * Datasheet: http://ams.com/eng/content/download/319364/1117183/file/TCS3472_Datasheet_EN_v2.pdf
>> - *
>> - * TODO: wait time
>> */
>>
>> #include <linux/cleanup.h>
>> @@ -53,19 +51,27 @@
>> #define TCS3472_STATUS_AINT BIT(4)
>> #define TCS3472_STATUS_AVALID BIT(0)
>> #define TCS3472_ENABLE_AIEN BIT(4)
>> +#define TCS3472_ENABLE_WEN BIT(3)
>> #define TCS3472_ENABLE_AEN BIT(1)
>> #define TCS3472_ENABLE_PON BIT(0)
>> +#define TCS3472_ENABLE_RUN \
>> + (TCS3472_ENABLE_AEN | TCS3472_ENABLE_PON | TCS3472_ENABLE_WEN)
>> #define TCS3472_CONTROL_AGAIN_MASK (BIT(0) | BIT(1))
>> +#define TCS3472_CONFIG_WLONG BIT(1)
>>
>> struct tcs3472_data {
>> struct i2c_client *client;
>> struct mutex lock;
>> + int target_freq_hz;
>> + int target_freq_uhz;
>> u16 low_thresh;
>> u16 high_thresh;
>> u8 enable;
>> u8 control;
>> u8 atime;
>> u8 apers;
>> + u8 wtime;
>> + bool wlong;
>> };
>>
>> static const struct iio_event_spec tcs3472_events[] = {
>> @@ -91,6 +97,7 @@ static const struct iio_event_spec tcs3472_events[] = {
>> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_CALIBSCALE) | \
>> BIT(IIO_CHAN_INFO_INT_TIME), \
>> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ), \
>> .channel2 = IIO_MOD_LIGHT_##_color, \
>> .address = _addr, \
>> .scan_index = _si, \
>> @@ -114,6 +121,47 @@ static const struct iio_chan_spec tcs3472_channels[] = {
>> IIO_CHAN_SOFT_TIMESTAMP(4),
>> };
>>
>> +/*
>> + * The chip's cycle time is the sum of three components:
>> + * - ATIME: the programmable RGBC integration time.
>> + * - The fixed RGBC initialization time (2400 us).
>> + * - WTIME: the wait time, used only if WEN is set. If WLONG is active,
>> + * the wait step is multiplied by 12 (2400 us -> 28800 us).
>> + */
>> +static unsigned int tcs3472_cycle_time_us(struct tcs3472_data *data)
>> +{
>> + unsigned int atime_us = (256 - data->atime) * 2400;
>> + unsigned int init_us = 2400;
>> + unsigned int wtime_us;
>> +
>> + if (!(data->enable & TCS3472_ENABLE_WEN))
>> + wtime_us = 0;
>> + else if (data->wlong)
>> + wtime_us = (256 - data->wtime) * 28800;
>> + else
>> + wtime_us = (256 - data->wtime) * 2400;
>> +
>> + return atime_us + init_us + wtime_us;
>> +}
>> +
>> +/*
>> + * Convert a cycle time in microseconds to a frequency in Hz and microhertz.
>> + *
>> + * Given cycle_us = T (the cycle period in microseconds), the corresponding
>> + * frequency is:
>> + * f = 1e6 / T [Hz]
>> + *
>> + * The result is split into the IIO_VAL_INT_PLUS_MICRO format:
>> + * val = floor(1e6 / T) [Hz]
>> + * val2 = (1e6 mod T) * 1e6 / T [microhertz]
>> + */
>> +static void tcs3472_cycle_to_freq(unsigned int cycle_us, int *val, int *val2)
>> +{
>> + *val = USEC_PER_SEC / cycle_us;
>> + *val2 = div_u64((u64)(USEC_PER_SEC % cycle_us) * USEC_PER_SEC,
>> + cycle_us);
>> +}
>> +
>> static int tcs3472_req_data(struct tcs3472_data *data)
>> {
>> int tries = 50;
>> @@ -166,16 +214,131 @@ static int tcs3472_read_raw(struct iio_dev *indio_dev,
>> *val = 0;
>> *val2 = (256 - data->atime) * 2400;
>> return IIO_VAL_INT_PLUS_MICRO;
>> + case IIO_CHAN_INFO_SAMP_FREQ: {
>> + unsigned int cycle_us = tcs3472_cycle_time_us(data);
>> +
>> + tcs3472_cycle_to_freq(cycle_us, val, val2);
>> + return IIO_VAL_INT_PLUS_MICRO;
>> + }
>> default:
>> return -EINVAL;
>> }
>> }
>>
>> +static int tcs3472_set_sampling_freq(struct tcs3472_data *data,
>> + int val, int val2)
>> +{
>> + unsigned int atime_us;
>> + unsigned int init_us = 2400;
>> + u64 cycle_us;
>> + s64 wait_us;
>> + int wtime;
>> + bool wlong = false;
>> + u8 config;
>> + int ret;
>> +
>> + if (val < 0 || val2 < 0 || (val == 0 && val2 == 0))
>> + return -EINVAL;
>> +
>> + guard(mutex)(&data->lock);
>> +
>> + atime_us = (256 - data->atime) * 2400;
>> + cycle_us = div64_u64(PSEC_PER_SEC,
>> + (u64)val * USEC_PER_SEC + val2);
>> +
>> + /*
>> + * wait_us can be negative when the requested frequency is too high
>> + * to be reached, or very large when the requested frequency is
>> + * close to zero. Use s64 to cover the full range:
>> + *
>> + * cycle_us = PSEC_PER_SEC / (val * USEC_PER_SEC + val2)
>> + *
>> + * The divisor of the formula above reaches its maximum when
>> + * val = val2 = INT_MAX:
>> + * INT_MAX * USEC_PER_SEC + INT_MAX = ~2.15e18
>> + * so cycle_us_min = floor(1e12 / 2.15e18) = 0.
>> + *
>> + * The divisor reaches its minimum (1) when val = 0 and val2 = 1,
>> + * so cycle_us_max = 1e12 / 1 = 1e12.
>> + *
>> + * Therefore:
>> + * wait_us_min = 0 - 2400 - 612000 = -616800
>> + * wait_us_max = 1e12 - 2400 - 2400 = 999999995200
>> + *
>> + * Both fit comfortably in s64.
>> + */
>> + wait_us = (s64)cycle_us - init_us - atime_us;
>> +
>> + if (wait_us < 2400) {
>> + if (data->enable & TCS3472_ENABLE_WEN) {
>> + data->enable &= ~TCS3472_ENABLE_WEN;
> As below.
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + TCS3472_ENABLE,
>> + data->enable);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + data->target_freq_hz = val;
>> + data->target_freq_uhz = val2;
>> + return 0;
>> + }
>> +
>> + /*
>> + * Wait state is needed: make sure WEN is active before programming
>> + * WTIME (and possibly WLONG).
>> + */
>> + if (!(data->enable & TCS3472_ENABLE_WEN)) {
>> + data->enable |= TCS3472_ENABLE_WEN;
>
> Similar to below. Can we only update data->enable if the write succeeds.
>
>> + ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE,
>> + data->enable);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + wtime = 256 - DIV_ROUND_CLOSEST_ULL(wait_us, 2400);
>> + if (wtime < 0) {
>> + wlong = true;
>> + wtime = 256 - DIV_ROUND_CLOSEST_ULL(wait_us, 28800);
>> + }
>> + wtime = clamp(wtime, 0, 255);
>> +
>> + if (wlong != data->wlong) {
>> + ret = i2c_smbus_read_byte_data(data->client, TCS3472_CONFIG);
>> + if (ret < 0)
>> + return ret;
>> +
>> + config = ret;
>> + if (wlong)
>> + config |= TCS3472_CONFIG_WLONG;
>> + else
>> + config &= ~TCS3472_CONFIG_WLONG;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client, TCS3472_CONFIG,
>> + config);
>> + if (ret)
>> + return ret;
>> +
>> + data->wlong = wlong;
>> + }
>> +
>> + ret = i2c_smbus_write_byte_data(data->client, TCS3472_WTIME, wtime);
>> + if (ret)
>> + return ret;
>> +
>> + data->wtime = wtime;
>> + data->target_freq_hz = val;
>> + data->target_freq_uhz = val2;
>> +
>> + return 0;
>> +}
>> +
>> static int tcs3472_write_raw(struct iio_dev *indio_dev,
>> struct iio_chan_spec const *chan,
>> int val, int val2, long mask)
>> {
>> struct tcs3472_data *data = iio_priv(indio_dev);
>> + int ret;
>> int i;
>>
>> switch (mask) {
>> @@ -196,15 +359,29 @@ static int tcs3472_write_raw(struct iio_dev *indio_dev,
>> if (val != 0)
>> return -EINVAL;
>> for (i = 0; i < 256; i++) {
>> - if (val2 == (256 - i) * 2400) {
>> - data->atime = i;
>> - return i2c_smbus_write_byte_data(
>> - data->client, TCS3472_ATIME,
>> - data->atime);
>> - }
>> -
>> + if (val2 != (256 - i) * 2400)
>> + continue;
>> +
>> + data->atime = i;
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + TCS3472_ATIME,
>> + data->atime);
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> + * ATIME just changed, so the cycle time changed too.
>> + * Re-run the sampling frequency logic to recompute
>> + * WTIME and preserve the user's last requested
>> + * frequency.
>> + */
>> + return tcs3472_set_sampling_freq(data,
>> + data->target_freq_hz,
>> + data->target_freq_uhz);
>> }
>> return -EINVAL;
>> + case IIO_CHAN_INFO_SAMP_FREQ:
>> + return tcs3472_set_sampling_freq(data, val, val2);
>> default:
>> return -EINVAL;
>> }
>> @@ -434,16 +611,15 @@ static const struct iio_info tcs3472_info = {
>> static int tcs3472_powerdown(struct tcs3472_data *data)
>> {
>> int ret;
>> - u8 enable_mask = TCS3472_ENABLE_AEN | TCS3472_ENABLE_PON;
>>
>> guard(mutex)(&data->lock);
>>
>> ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE,
>> - data->enable & ~enable_mask);
>> + data->enable & ~TCS3472_ENABLE_RUN);
>> if (ret)
>> return ret;
>>
>> - data->enable &= ~enable_mask;
>> + data->enable &= ~TCS3472_ENABLE_RUN;
> This would be more consistent and easier to read if you have
> u8 value;
>
> value = data->enable & ~TCS3472_ENABLE_AEN | TCS3472_ENABLE_PON
> value &= ~TCS3472_ENABLE_RUN;
>
> ret = i2c_...
> if (ret)
> return ret;
>
> data->enable = value;
>
> return 0;
>
> Or something along those lines. No need for separate enable_mask local
> variable.
>
> >
>> return 0;
>> }
>> @@ -458,6 +634,7 @@ static int tcs3472_probe(struct i2c_client *client)
>> struct device *dev = &client->dev;
>> struct tcs3472_data *data;
>> struct iio_dev *indio_dev;
>> + unsigned int cycle_us;
>> int ret;
>>
>> indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
>> @@ -498,6 +675,16 @@ static int tcs3472_probe(struct i2c_client *client)
>> return ret;
>> data->atime = ret;
>>
>> + ret = i2c_smbus_read_byte_data(data->client, TCS3472_WTIME);
>> + if (ret < 0)
>> + return ret;
>> + data->wtime = ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client, TCS3472_CONFIG);
>> + if (ret < 0)
>> + return ret;
>> + data->wlong = (ret & TCS3472_CONFIG_WLONG) ? 1 : 0;
>> +
>> ret = i2c_smbus_read_word_data(data->client, TCS3472_AILT);
>> if (ret < 0)
>> return ret;
>> @@ -518,14 +705,29 @@ static int tcs3472_probe(struct i2c_client *client)
>> if (ret < 0)
>> return ret;
>>
>> - /* enable device */
>> - data->enable = ret | TCS3472_ENABLE_PON | TCS3472_ENABLE_AEN;
>> + /*
>> + * Enable the chip in its full running state, including WEN. The
>> + * actual wait time is controlled by the WTIME and WLONG registers,
>> + * which retain their power-on defaults until userspace writes to
>> + * sampling_frequency.
>> + */
>> + data->enable = ret | TCS3472_ENABLE_RUN;
>> data->enable &= ~TCS3472_ENABLE_AIEN;
>
> Here is a case that should look more like the one that follows.
> Use a local variable to build what is written and update the cache
> only if the write succeeds.
>
>> ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE,
>> data->enable);
>> if (ret < 0)
>> return ret;
>>
>> + /*
>> + * Initialize target frequency from the chip's current state so that
>> + * subsequent integration_time changes via IIO_CHAN_INFO_INT_TIME can
>> + * preserve a meaningful sampling rate, even before userspace writes
>> + * sampling_frequency for the first time.
>> + */
>> + cycle_us = tcs3472_cycle_time_us(data);
>> + tcs3472_cycle_to_freq(cycle_us, &data->target_freq_hz,
>> + &data->target_freq_uhz);
>> +
>> ret = devm_add_action_or_reset(dev, tcs3472_powerdown_action, data);
>> if (ret)
>> return ret;
>> @@ -561,16 +763,23 @@ static int tcs3472_resume(struct device *dev)
>> struct tcs3472_data *data = iio_priv(i2c_get_clientdata(
>> to_i2c_client(dev)));
>> int ret;
>> - u8 enable_mask = TCS3472_ENABLE_AEN | TCS3472_ENABLE_PON;
>> + u8 value;
>>
>> guard(mutex)(&data->lock);
>>
>> - ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE,
>> - data->enable | enable_mask);
>> + /*
>> + * On resume, only PON and AEN need to be re-asserted. WEN must not
>> + * be forced on: its desired state was set by the user via
>> + * sampling_frequency and is already stored in data->enable, so we
>> + * read it from there to preserve the user's choice.
>> + */
>> + value = data->enable | TCS3472_ENABLE_PON | TCS3472_ENABLE_AEN;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE, value);
>> if (ret)
>> return ret;
>>
>> - data->enable |= enable_mask;
>> + data->enable = value;
>>
>> return 0;
>> }
>
Hi Jonathan,
Thanks for the review. I'd like to ask a design
question about Sashiko's finding on the cached data->enable.
Sashiko pointed out:
> @@ -434,16 +611,15 @@ static const struct iio_info tcs3472_info = {
> static int tcs3472_powerdown(struct tcs3472_data *data)
> {
> int ret;
> - u8 enable_mask = TCS3472_ENABLE_AEN | TCS3472_ENABLE_PON;
>
> guard(mutex)(&data->lock);
>
> ret = i2c_smbus_write_byte_data(data->client, TCS3472_ENABLE,
> - data->enable & ~enable_mask);
> + data->enable & ~TCS3472_ENABLE_RUN);
> if (ret)
> return ret;
>
> - data->enable &= ~enable_mask;
> + data->enable &= ~TCS3472_ENABLE_RUN;
Does this permanently lose the WEN configuration after a suspend/resume cycle?
Because TCS3472_ENABLE_WEN is part of the TCS3472_ENABLE_RUN mask, this clears
the WEN bit in the cached data->enable. Upon resume, tcs3472_resume() attempts
to restore the configuration by reading this cache:
value = data->enable | TCS3472_ENABLE_PON | TCS3472_ENABLE_AEN;
But since the WEN bit was permanently cleared in the cache during suspend, the
device always resumes with WEN disabled, discarding the user's sampling
frequency configuration.
I see two possible fixes:
1. In tcs3472_powerdown(), clear only PON and AEN from data->enable
(keeping WEN as the "user's last desired state"). This is minimal
but introduces a divergence between data->enable and the actual
hardware ENABLE register, which breaks the simple "cache of the
HW register" semantic.
2. Add a separate field (e.g. bool target_wen) that holds the user's
desired WEN state, set in tcs3472_set_sampling_freq() and read
back in tcs3472_resume(). data->enable then strictly remains a
pure cache of the HW register.
With solution2, the functions would behave as follows:
- tcs3472_set_sampling_freq(): when activating wait state, sets
target_wen = true; when disabling it (frequency too high), sets
target_wen = false. data->enable is then updated to match what
is written to the chip.
- tcs3472_cycle_time_us(): reads target_wen instead of
(data->enable & WEN) to decide whether to include wtime_us in
the cycle. This avoids reporting a stale wait time during a
suspended state.
- tcs3472_powerdown(): unchanged in semantics clears PON, AEN
and WEN from both the chip and data->enable. target_wen is left
untouched, since it represents the user's wish, not the HW
state.
- tcs3472_resume(): rebuilds the ENABLE value from
PON | AEN | (target_wen ? WEN : 0), writes it to the chip, then
updates data->enable to match.
- tcs3472_probe(): initializes target_wen from the chip's current
WEN bit (read at probe time).
Solution 2 feels cleaner to me, but it adds a field and a bit of
synchronization between target_wen and (data->enable & WEN). Do you
have another approach in mind?
Thanks,
Aldo
next prev parent reply other threads:[~2026-05-26 15:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 12:34 [PATCH v3 0/8] iio: tcs3472: cleanups, devm conversion and wait time Aldo Conte
2026-05-22 12:34 ` [PATCH v3 1/8] iio: tcs3472: power down chip on probe failure Aldo Conte
2026-05-22 12:34 ` [PATCH v3 2/8] iio: tcs3472: sort headers alphabetically Aldo Conte
2026-05-22 12:34 ` [PATCH v3 3/8] iio: tcs3472: convert remaining locking to guard(mutex) Aldo Conte
2026-05-26 12:57 ` Jonathan Cameron
2026-05-22 12:34 ` [PATCH v3 4/8] iio: tcs3472: use ! instead of explicit NULL check Aldo Conte
2026-05-26 12:58 ` Jonathan Cameron
2026-06-04 8:31 ` Andy Shevchenko
2026-06-04 8:38 ` Joshua Crofts
2026-06-04 10:37 ` Jonathan Cameron
2026-05-22 12:34 ` [PATCH v3 5/8] iio: tcs3472: use devm for resource management Aldo Conte
2026-05-26 13:00 ` Jonathan Cameron
2026-05-22 12:34 ` [PATCH v3 6/8] iio: tcs3472: use local struct device * for remaining cases Aldo Conte
2026-05-26 13:04 ` Jonathan Cameron
2026-05-22 12:34 ` [PATCH v3 7/8] iio: tcs3472: move standalone return to default case Aldo Conte
2026-05-22 12:34 ` [PATCH v3 8/8] iio: tcs3472: implement wait time and sampling frequency Aldo Conte
2026-05-26 13:11 ` Jonathan Cameron
2026-05-26 15:10 ` Aldo Conte [this message]
2026-05-26 16:52 ` Jonathan Cameron
2026-06-04 8:10 ` Aldo Conte
2026-06-04 10:42 ` Jonathan Cameron
2026-06-04 9:23 ` Aldo Conte
2026-06-06 9:27 ` Aldo Conte
2026-06-06 14:09 ` Jonathan Cameron
2026-06-07 9:44 ` Aldo Conte
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=5557d9b9-9869-45ce-9c28-cb24cdb03cda@gmail.com \
--to=aldocontelk@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=joshua.crofts1@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=shuah@kernel.org \
/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