Re: [PATCH 2/2] iio: magnetometer: add Infineon TLE493D-W2B6 driver

[Viral Patel]

On Fri, 6 Nov 2026 03:04:00 +0000, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> Seems sashiko isn't done with this one yet ...

It has finished now and reported no issues on either patch.

> Use FIELD_GET() to extract the 1 bit values as well.

Will do.

> Why do this after setting data->regs[TLE493_REG_DIAG]?

It's deliberate: the cached Diag holds the frame counter of the last
frame read, and the next measurement waits for FRM to change. Updating
it even for a rejected frame means that frame is not treated as new
next time. I'll add a comment.

> I'd be tempted to just hold the lock a bit long and do the simpler
> case IIO_CHAN_INFO_RAW: {
> guard()...
>
> ...
> return IIO_VAL_INT;
> }

Ok, will simplify.

> Generally avoid any use of cleanup.h magic in a function with
> a goto.

Will switch to mutex_lock()/mutex_unlock().

>       for (unsigned int i = 0; ...

Will change.

> Is it same as SMBUS Quick?  If so use that.

Yes, the reset frames are Quick commands (read at 0x7f, write at
0x00). v2 will use I2C_SMBUS_QUICK and skip the reset when the adapter
lacks I2C_FUNC_SMBUS_QUICK. Note 0x00 is the general call address, so other
devices that respond to general call will see an empty write; this follows
the manual's reset sequence. The Pi 5 controller doesn't support Quick, so
the reset was not exercised in my testing.

> Can you add a few comments on what this iicadr is for.

IICadr in MOD1 selects which of the four addresses the sensor responds
on (User Manual v1.11, MOD1 and Table 4), and every MOD1 write includes
it. The manual's write example notes that IICadr must be kept at the
current value so the address doesn't change, so the driver has to
write the value matching the address the device is on. That's why an
address outside the list fails probe: there is no correct value to
write. The ID check is only informational. I'll add a comment.

Thanks,
Viral