[PATCH 1/3] iio: adc: mt6359-auxadc: correct channel types to IIO_VOLTAGE

Roman Vivchar rva333 at protonmail.com
Tue Nov 10 12:39:47 PST 2026


Hi Jonathan,

On Wednesday, November 4th, 2026 at 1:42 AM, Jonathan Cameron <jic23 at kernel.org> wrote:

> On Tue, 03 Nov 2026 18:32:07 +0200
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com at kernel.org> wrote:

...

> >
> > Correct all channel types to IIO_VOLTAGE.
> >
> > Fixes: 3587914bf61d ("iio: adc: Add support for MediaTek MT6357/8/9 Auxiliary ADC")
> > Fixes: d6f49313272b ("iio: adc: mt6359: Add support for MediaTek MT6363 PMIC AUXADC")
> > Signed-off-by: Roman Vivchar <rva333 at protonmail.com>
> 
> This one makes me very nervous, not because it is wrong but rather
> because there may be a bunch of userspace relying on these wrong
> channel types.
> 
> It is horrible but I think we can't touch that :(  What we can do is
> put the right interface in place as well. Thankfully it looks like
> the channel index is independent of the channel type so we can duplicate
> the wrong channels with voltage ones + some comments to make sure this
> doesn't propagate to any new supported devices.

Sorry I forgot to include this in my previous reply, but do you suggest
duplicating the old channels and adding the fixed ones as separate entries?

That would cause issues for in-kernel consumers. In my tree I have a
battery thermal zone driven by ntc_thermistor (which is actually how I
found this bug, as it refused to probe due to the wrong channel type),
and I will soon send a new revision of the PMIC thermal driver. They all
require IIO_VOLTAGE channels to operate properly. If we duplicate the
channels, consumers will get the wrong type unless we reorder the array
or add a custom xlate callback.

Existing userspace tools would get bogus values from the current ABI
anyway. The driver applies a raw mV scale to all channels, while thermal
needs efuse calibration with a special formula applied, and even plain
voltage channels like bat_adc and cdt_v were mislabeled as resistance and
temperature.

Given all this, I think it's better to simply fix channel types.

Best regards,
Roman



More information about the linux-arm-kernel mailing list