linux-kernel - Re: [PATCH v3 1/2] iio: magnetometer: add support for Infineon TLV493D 3D Magentic sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aJdcUhz-vqnx8DwA@dixit>
Date: Sat, 9 Aug 2025 20:03:54 +0530
From: Dixit Parmar <dixitparmar19@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 1/2] iio: magnetometer: add support for Infineon
 TLV493D 3D Magentic sensor

On Sat, Aug 09, 2025 at 02:44:00PM +0200, Andy Shevchenko wrote:
> > > > +       data->wr_regs[TLV493D_WR_REG_MODE1] |= mode1_cfg;
> > > > +       data->wr_regs[TLV493D_WR_REG_MODE2] |= mode2_cfg;
> > >
> > > No mask for the existing values in the respective wr_regs? Wouldn't
> > > you need to use FIELD_MODIFY() instead?
> > >
> > I believe, we are doing OR op with the value created using FIELD_PREP,
> > so it should not interefere with the existing non-masked values.
> 
> I am talking about existing values in the array.
>
Right. So in that I think it will make more sense to directly use
FIELD_MODIFY instead of using FIELD_PREP first and then doing this OR
op. Right?
> > However, as FIELD_MODIFY is there, I should utilize it.
> 
> > > > +       u16 val = 0;
> > >
> > > I would move the default assignment to the 'default' case. This makes
> > > the intention clearer.
> > >
> > As per the suggestion on privious version of the patch, we are having
> > ch datatype as enum and as suggested, with enum as swicth-case, it
> > should not have default case. so I think this initialisation to 0 at the
> > beginning should be fine.
> 
> It will make no sense. Please, remove it. and perhaps the compiler
> won't warn, otherwise the default case will be needed.
>
Understood. Will keep it uninitialized.

> > > Missing include for this macro I believe.
> > >
> > No I guess. DEFINE_RUNTIME_DEV_PM_OPS is part of pm_runtime.h and its
> > already included.
> 
> And how is it related to my comment _here_ in the code?
Pardon my misunderstanding. Please ignore.

> > > > +       },
> > > > +       .probe = tlv493d_probe,
> > > > +       .id_table = tlv493d_id,
> > > > +};
> 
> -- 
> With Best Regards,
> Andy Shevchenko