Hello Jonathan,
On Sun, Feb 25, 2024 at 12:07:00PM +0000, Jonathan Cameron wrote:
> On Thu, 22 Feb 2024 02:13:37 +0100
> Ondřej Jirman <megi@xxxxxx> wrote:
>
> > From: Icenowy Zheng <icenowy@xxxxxxx>
> >
> > AF8133J is a simple I2C-connected magnetometer, without interrupts.
> >
> > Add a simple IIO driver for it.
> >
> > Co-developed-by: Icenowy Zheng <icenowy@xxxxxxx>
> > Signed-off-by: Icenowy Zheng <icenowy@xxxxxxx>
> Check patch correct moaned that Icenowy is the author (from:)
> so doesn't need a co-developed.
>
> > Signed-off-by: Dalton Durst <dalton@xxxxxxxxxxx>
> > Signed-off-by: Shoji Keita <awaittrot@xxxxxxx>
> > Co-developed-by: Ondrej Jirman <megi@xxxxxx>
> > Signed-off-by: Ondrej Jirman <megi@xxxxxx>
> > Reviewed-by: Andrey Skvortsov <andrej.skvortzov@xxxxxxxxx>
> > Tested-by: Andrey Skvortsov <andrej.skvortzov@xxxxxxxxx>
>
> Hi.
>
> A few really minor things noticed during a final review.
> I'll tweak them whilst applying. Diff is
Thank you very much for finishing touches.
> > +static int af8133j_product_check(struct af8133j_data *data)
> > +{
> > + struct device *dev = &data->client->dev;
> > + unsigned int val;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, AF8133J_REG_PCODE, &val);
> > + if (ret) {
> > + dev_err(dev, "Error reading product code (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + if (val != AF8133J_REG_PCODE_VAL) {
> > + dev_err(dev, "Invalid product code (0x%02x)\n", val);
> > + return -EINVAL;
>
> This should be warn only and we should carry on regardless. The reason
> behind this is to support fallback compatible values in DT to potentially enable
> a newer device to be supported on an older kernel.
>
> Many IIO drivers do this wrong as my understanding on what counted on
> 'compatible' used to be different. Long discussions on this with the DT
> maintainers led me to accept that letting ID checks fail was fine, but
> that a message was appropriate. Often a fail here actually means no device.
> We have some exceptions to this rule for devices where we know the same
> FW ids are in use in the wild for devices supported by different Linux
> drivers - but those are thankfully rare!
Makes sense. If newer device variant has the same register meanings, but just
a different ID register, this way it can be supported without driver
modifications. I'll keep it in mind when doing ID checks in other drivers.
Thanks for all your detailed notes during the review. I learned a few
new subtleties.
Kind regards,
o.
> > + }
> > +
> > + return 0;
> > +}
> > +
> }
>
> > +static const int af8133j_scales[][2] = {
> > + [0] = { 0, 366210 }, // 12 gauss
> > + [1] = { 0, 671386 }, // 22 gauss
> Trivial so I'll fix it up: IIO comments are /* */
> not C++ style (with exception of the SPDX stuff that needs to be).
> > +};
>
>
>
