[PATCH 0/7] hwmon: zero-initialization instead of memset

[PATCH 0/7] hwmon: zero-initialization instead of memset

[Manish Baing]

Hi all,

This patch series cleans up memory initialization across several
hardware monitoring (hwmon) drivers by replacing explicit memset() calls
with empty brace initialization (= {}).

Following similar cleanups in the IIO subsystem [1], this series updates 
these drivers to stop using memset() for stack memory initialization.
As noted in those discussions [2], using empty brace initialization (= {})
is the preferred approach. 

Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
were using memset() inside a for-loop. To fix this, the variable 
declarationwas moved directly inside the loop and zero-initialized there. 
This safely resets the data on every iteration and makes the code much 
cleaner.

Testing:
- Compiled all modified files using `make W=1` with no warnings or errors. 

[1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
[2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/

Manish Baing (7):
  hwmon: drivetemp: Use zero-initialization instead of memset()
  hwmon: f71882fg: Use zero-initialization instead of memset()
  hwmon: ltc2947-core: Use zero-initialization instead of memset()
  hwmon: nct6683: Use zero-initialization instead of memset()
  hwmon: nct6775-platform: Use zero-initialization instead of memset()
  hwmon: pmbus: adm1266: Use zero-initialization instead of memset()
  hwmon: it87: Use zero-initialization instead of memset()

 drivers/hwmon/drivetemp.c        | 3 +--
 drivers/hwmon/f71882fg.c         | 4 +---
 drivers/hwmon/it87.c             | 3 +--
 drivers/hwmon/ltc2947-core.c     | 4 +---
 drivers/hwmon/nct6683.c          | 4 ++--
 drivers/hwmon/nct6775-platform.c | 4 ++--
 drivers/hwmon/pmbus/adm1266.c    | 4 +---
 7 files changed, 9 insertions(+), 17 deletions(-)

-- 
2.43.0

[PATCH 1/7] hwmon: drivetemp: Use zero-initialization instead of memset()

[Manish Baing]

Use empty brace initialization (={}) instead of explicit memset()
to zero-initialize stack memory to simplify the code.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/drivetemp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hwmon/drivetemp.c b/drivers/hwmon/drivetemp.c
index 002e0660a0b8..b75cd5f5246e 100644
--- a/drivers/hwmon/drivetemp.c
+++ b/drivers/hwmon/drivetemp.c
@@ -161,11 +161,10 @@ static int drivetemp_scsi_command(struct drivetemp_data *st,
 				 u8 ata_command, u8 feature,
 				 u8 lba_low, u8 lba_mid, u8 lba_high)
 {
-	u8 scsi_cmd[MAX_COMMAND_SIZE];
+	u8 scsi_cmd[MAX_COMMAND_SIZE] = { };
 	enum req_op op;
 	int err;
 
-	memset(scsi_cmd, 0, sizeof(scsi_cmd));
 	scsi_cmd[0] = ATA_16;
 	if (ata_command == ATA_CMD_SMART && feature == SMART_WRITE_LOG) {
 		scsi_cmd[1] = (5 << 1);	/* PIO Data-out */
-- 
2.43.0

[PATCH 2/7] hwmon: f71882fg: Use zero-initialization instead of memset()

[Manish Baing]

Use empty brace initialization (={}) instead of explicit memset()
to zero-initialize stack memory to simplify the code.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/f71882fg.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c
index 204059d2de6c..c1d02d4e7b76 100644
--- a/drivers/hwmon/f71882fg.c
+++ b/drivers/hwmon/f71882fg.c
@@ -2667,9 +2667,7 @@ static int __init f71882fg_init(void)
 {
 	int err;
 	int address;
-	struct f71882fg_sio_data sio_data;
-
-	memset(&sio_data, 0, sizeof(sio_data));
+	struct f71882fg_sio_data sio_data = { };
 
 	address = f71882fg_find(0x2e, &sio_data);
 	if (address < 0)
-- 
2.43.0

[PATCH 3/7] hwmon: ltc2947-core: Use zero-initialization instead of memset()

[Manish Baing]

Use empty brace initialization (={}) instead of explicit memset()
to zero-initialize stack memory to simplify the code.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/ltc2947-core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/ltc2947-core.c b/drivers/hwmon/ltc2947-core.c
index ad7120d1e469..d95265986b18 100644
--- a/drivers/hwmon/ltc2947-core.c
+++ b/drivers/hwmon/ltc2947-core.c
@@ -273,11 +273,9 @@ static int ltc2947_alarm_read(struct ltc2947_data *st, const u8 reg,
 {
 	u8 offset = reg - LTC2947_REG_STATUS;
 	/* +1 to include status reg */
-	char alarms[LTC2947_ALERTS_SIZE + 1];
+	char alarms[LTC2947_ALERTS_SIZE + 1] = { };
 	int ret = 0;
 
-	memset(alarms, 0, sizeof(alarms));
-
 	ret = regmap_write(st->map, LTC2947_REG_PAGE_CTRL, LTC2947_PAGE0);
 	if (ret)
 		return ret;
-- 
2.43.0

[PATCH 4/7] hwmon: nct6683: Use zero-initialization instead of memset()

[Manish Baing]

Reduce the scope of 'struct resource res' by moving it inside the for-loop
and using empty brace initialization (= {}). This ensures the structure is
safely zero-initialized on every iteration, allowing for the safe removal
of explicit memset() call.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/nct6683.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
index 0581770380cc..bd30867f9e7c 100644
--- a/drivers/hwmon/nct6683.c
+++ b/drivers/hwmon/nct6683.c
@@ -1437,7 +1437,6 @@ static int __init sensors_nct6683_init(void)
 {
 	struct nct6683_sio_data sio_data;
 	int sioaddr[2] = { 0x2e, 0x4e };
-	struct resource res;
 	bool found = false;
 	int address;
 	int i, err;
@@ -1454,6 +1453,8 @@ static int __init sensors_nct6683_init(void)
 	 * nct6683 hardware monitor, and call probe()
 	 */
 	for (i = 0; i < ARRAY_SIZE(pdev); i++) {
+		struct resource res = { };
+
 		address = nct6683_find(sioaddr[i], &sio_data);
 		if (address <= 0)
 			continue;
@@ -1471,7 +1472,6 @@ static int __init sensors_nct6683_init(void)
 		if (err)
 			goto exit_device_put;
 
-		memset(&res, 0, sizeof(res));
 		res.name = DRVNAME;
 		res.start = address + IOREGION_OFFSET;
 		res.end = address + IOREGION_OFFSET + IOREGION_LENGTH - 1;
-- 
2.43.0

[PATCH 5/7] hwmon: nct6775-platform: Use zero-initialization instead of memset()

[Manish Baing]

Reduce the scope of 'struct resource res' by moving it inside the for-loop
and using empty brace initialization (= {}). This ensures the structure is
safely zero-initialized on every iteration, allowing for the safe removal
of explicit memset() call.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/nct6775-platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/nct6775-platform.c b/drivers/hwmon/nct6775-platform.c
index 1975399ac440..b73086a56d97 100644
--- a/drivers/hwmon/nct6775-platform.c
+++ b/drivers/hwmon/nct6775-platform.c
@@ -1528,7 +1528,6 @@ static int __init sensors_nct6775_platform_init(void)
 	int i, err;
 	bool found = false;
 	int address;
-	struct resource res;
 	struct nct6775_sio_data sio_data;
 	int sioaddr[2] = { 0x2e, 0x4e };
 	enum sensor_access access = access_direct;
@@ -1562,6 +1561,8 @@ static int __init sensors_nct6775_platform_init(void)
 	 * nct6775 hardware monitor, and call probe()
 	 */
 	for (i = 0; i < ARRAY_SIZE(pdev); i++) {
+		struct resource res = { };
+
 		sio_data.sio_outb = superio_outb;
 		sio_data.sio_inb = superio_inb;
 		sio_data.sio_select = superio_select;
@@ -1596,7 +1597,6 @@ static int __init sensors_nct6775_platform_init(void)
 			goto exit_device_put;
 
 		if (sio_data.access == access_direct) {
-			memset(&res, 0, sizeof(res));
 			res.name = DRVNAME;
 			res.start = address + IOREGION_OFFSET;
 			res.end = address + IOREGION_OFFSET + IOREGION_LENGTH - 1;
-- 
2.43.0

[PATCH 6/7] hwmon: pmbus: adm1266: Use zero-initialization instead of memset()

[Manish Baing]

Use empty brace initialization (={}) instead of explicit memset()
to zero-initialize stack memory to simplify the code.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/pmbus/adm1266.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
index 6f6ad7b20e9a..806b92473a4f 100644
--- a/drivers/hwmon/pmbus/adm1266.c
+++ b/drivers/hwmon/pmbus/adm1266.c
@@ -449,13 +449,11 @@ static int adm1266_config_nvmem(struct adm1266_data *data)
 static int adm1266_set_rtc(struct adm1266_data *data)
 {
 	time64_t kt;
-	char write_buf[6];
+	char write_buf[6] = { };
 	int i;
 
 	kt = ktime_get_real_seconds();
 
-	memset(write_buf, 0, sizeof(write_buf));
-
 	for (i = 0; i < 4; i++)
 		write_buf[2 + i] = (kt >> (i * 8)) & 0xFF;
 
-- 
2.43.0

[PATCH 7/7] hwmon: it87: Use zero-initialization instead of memset()

[Manish Baing]

Reduce the scope of 'struct it87_sio_data sio_data' by moving it inside
the for-loop and using empty brace initialization (= {}). This ensures
the structure is safely zero-initialized on every iteration, allowing for
the safe removal of the explicit memset() call.

No functional change.

Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
 drivers/hwmon/it87.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 5fd310662ee4..f3f8d835ff92 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -3777,7 +3777,6 @@ MODULE_DEVICE_TABLE(dmi, it87_dmi_table);
 static int __init sm_it87_init(void)
 {
 	int sioaddr[2] = { REG_2E, REG_4E };
-	struct it87_sio_data sio_data;
 	unsigned short isa_address[2];
 	bool found = false;
 	int i, err;
@@ -3789,7 +3788,7 @@ static int __init sm_it87_init(void)
 	dmi_check_system(it87_dmi_table);
 
 	for (i = 0; i < ARRAY_SIZE(sioaddr); i++) {
-		memset(&sio_data, 0, sizeof(struct it87_sio_data));
+		struct it87_sio_data sio_data = { };
 		isa_address[i] = 0;
 		err = it87_find(sioaddr[i], &isa_address[i], &sio_data, i);
 		if (err || isa_address[i] == 0)
-- 
2.43.0

Re: [PATCH 7/7] hwmon: it87: Use zero-initialization instead of memset()

[Manish Baing]

Hi all,

The Sashiko AI bot flagged that replacing memset() with empty brace
initialization {} here might leave padding bytes uninitialized.

 How would you prefer to proceed?   Please let me know in case I need
to send a v2 to address this.

 Sashiko AI review ·
https://sashiko.dev/#/patchset/20260530221353.159461-1-manishbaing2789@gmail.com?part=7

Thanks & Regards,

Manish


On Sun, May 31, 2026 at 3:44 AM Manish Baing <manishbaing2789@gmail.com> wrote:
>
> Reduce the scope of 'struct it87_sio_data sio_data' by moving it inside
> the for-loop and using empty brace initialization (= {}). This ensures
> the structure is safely zero-initialized on every iteration, allowing for
> the safe removal of the explicit memset() call.
>
> No functional change.
>
> Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
> ---
>  drivers/hwmon/it87.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
> index 5fd310662ee4..f3f8d835ff92 100644
> --- a/drivers/hwmon/it87.c
> +++ b/drivers/hwmon/it87.c
> @@ -3777,7 +3777,6 @@ MODULE_DEVICE_TABLE(dmi, it87_dmi_table);
>  static int __init sm_it87_init(void)
>  {
>         int sioaddr[2] = { REG_2E, REG_4E };
> -       struct it87_sio_data sio_data;
>         unsigned short isa_address[2];
>         bool found = false;
>         int i, err;
> @@ -3789,7 +3788,7 @@ static int __init sm_it87_init(void)
>         dmi_check_system(it87_dmi_table);
>
>         for (i = 0; i < ARRAY_SIZE(sioaddr); i++) {
> -               memset(&sio_data, 0, sizeof(struct it87_sio_data));
> +               struct it87_sio_data sio_data = { };
>                 isa_address[i] = 0;
>                 err = it87_find(sioaddr[i], &isa_address[i], &sio_data, i);
>                 if (err || isa_address[i] == 0)
> --
> 2.43.0
>

Re: [PATCH 0/7] hwmon: zero-initialization instead of memset

[Guenter Roeck]

On 5/30/26 15:13, Manish Baing wrote:
> Hi all,
> 
> This patch series cleans up memory initialization across several
> hardware monitoring (hwmon) drivers by replacing explicit memset() calls
> with empty brace initialization (= {}).
> 
> Following similar cleanups in the IIO subsystem [1], this series updates
> these drivers to stop using memset() for stack memory initialization.
> As noted in those discussions [2], using empty brace initialization (= {})
> is the preferred approach.
> 
> Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
> were using memset() inside a for-loop. To fix this, the variable
> declarationwas moved directly inside the loop and zero-initialized there.
> This safely resets the data on every iteration and makes the code much
> cleaner.
> 
> Testing:
> - Compiled all modified files using `make W=1` with no warnings or errors.
> 
> [1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
> [2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/

That discussion does not fully address a problem I had seen previously,
where {} did _not_ zero-fill all holes, causing subsequent memcmp()
failures on affected data structures. It took a lot a lot of debugging
to find and fix that problem. Given that, I am not inclined to accept
this series unless someone convinces me that it fixes an actual problem
_and_ that each and every instance of the changes is not used in a
subsequent memcmp().

Guenter

Re: [PATCH 0/7] hwmon: zero-initialization instead of memset

[Manish Baing]

Hi Guenter,

Thank you for catching the struct padding risk. You are completely
right—Patch 7 (it87.c) would trigger a KMSAN uninit-value warning due
to the kmemdup() copy in platform_device_add_data(). I will drop that
patch entirely.

I have audited the other six drivers in this series and verified that
their variables are never passed to memcmp(), kmemdup(), or hashed, so
the = {} initialization is perfectly safe there.

While this does not fix an active bug, the goal is to follow a cleanup
pattern  recently discussed for the IIO subsystem [1],[2]
1.Better performance: It removes the need for an extra function call.
Instead, the compiler clears the memory directly and more efficiently.
2.Safer code: It prevents accidental memory leaks that happen when
developers make a typo in the sizeof() calculation.

Would you be open to a v2 that includes just the six safe patches to
modernize these initializations?

[1] https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
[2] https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/

Thanks for your time and guidance,

Thanks & Regards,
Manish

On Sun, Jun 7, 2026 at 9:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 5/30/26 15:13, Manish Baing wrote:
> > Hi all,
> >
> > This patch series cleans up memory initialization across several
> > hardware monitoring (hwmon) drivers by replacing explicit memset() calls
> > with empty brace initialization (= {}).
> >
> > Following similar cleanups in the IIO subsystem [1], this series updates
> > these drivers to stop using memset() for stack memory initialization.
> > As noted in those discussions [2], using empty brace initialization (= {})
> > is the preferred approach.
> >
> > Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
> > were using memset() inside a for-loop. To fix this, the variable
> > declarationwas moved directly inside the loop and zero-initialized there.
> > This safely resets the data on every iteration and makes the code much
> > cleaner.
> >
> > Testing:
> > - Compiled all modified files using `make W=1` with no warnings or errors.
> >
> > [1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
> > [2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
>
> That discussion does not fully address a problem I had seen previously,
> where {} did _not_ zero-fill all holes, causing subsequent memcmp()
> failures on affected data structures. It took a lot a lot of debugging
> to find and fix that problem. Given that, I am not inclined to accept
> this series unless someone convinces me that it fixes an actual problem
> _and_ that each and every instance of the changes is not used in a
> subsequent memcmp().
>
> Guenter
>

Re: [PATCH 0/7] hwmon: zero-initialization instead of memset

[Guenter Roeck]

On 6/25/26 09:04, Manish Baing wrote:
> Hi Guenter,
> 
> Thank you for catching the struct padding risk. You are completely
> right—Patch 7 (it87.c) would trigger a KMSAN uninit-value warning due
> to the kmemdup() copy in platform_device_add_data(). I will drop that
> patch entirely.
> 
> I have audited the other six drivers in this series and verified that
> their variables are never passed to memcmp(), kmemdup(), or hashed, so
> the = {} initialization is perfectly safe there.
> 
> While this does not fix an active bug, the goal is to follow a cleanup
> pattern  recently discussed for the IIO subsystem [1],[2]
> 1.Better performance: It removes the need for an extra function call.
> Instead, the compiler clears the memory directly and more efficiently.
> 2.Safer code: It prevents accidental memory leaks that happen when
> developers make a typo in the sizeof() calculation.
> 
> Would you be open to a v2 that includes just the six safe patches to
> modernize these initializations?
> 

Not really. I would not mind if there was a safe means to initialize
a data structure without risking holes and without memset(). In the
absence of that I rather play safe than sorry (and apparently we have
a different opinion about the definition of "safe").

Guenter

> [1] https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
> [2] https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
> 
> Thanks for your time and guidance,
> 
> Thanks & Regards,
> Manish
> 
> On Sun, Jun 7, 2026 at 9:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 5/30/26 15:13, Manish Baing wrote:
>>> Hi all,
>>>
>>> This patch series cleans up memory initialization across several
>>> hardware monitoring (hwmon) drivers by replacing explicit memset() calls
>>> with empty brace initialization (= {}).
>>>
>>> Following similar cleanups in the IIO subsystem [1], this series updates
>>> these drivers to stop using memset() for stack memory initialization.
>>> As noted in those discussions [2], using empty brace initialization (= {})
>>> is the preferred approach.
>>>
>>> Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
>>> were using memset() inside a for-loop. To fix this, the variable
>>> declarationwas moved directly inside the loop and zero-initialized there.
>>> This safely resets the data on every iteration and makes the code much
>>> cleaner.
>>>
>>> Testing:
>>> - Compiled all modified files using `make W=1` with no warnings or errors.
>>>
>>> [1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
>>> [2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
>>
>> That discussion does not fully address a problem I had seen previously,
>> where {} did _not_ zero-fill all holes, causing subsequent memcmp()
>> failures on affected data structures. It took a lot a lot of debugging
>> to find and fix that problem. Given that, I am not inclined to accept
>> this series unless someone convinces me that it fixes an actual problem
>> _and_ that each and every instance of the changes is not used in a
>> subsequent memcmp().
>>
>> Guenter
>>
> 

Re: [PATCH 0/7] hwmon: zero-initialization instead of memset

[Manish Baing]

Hi Guenter,
That makes complete sense.
I understand the risks of leaving padding bytes uninitialized now.
Thank you for taking the time to explain the rationale! it is a very
valuable learning experience.

Thanks & Regards
Manish Baing

On Fri, Jun 26, 2026 at 7:29 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 6/25/26 09:04, Manish Baing wrote:
> > Hi Guenter,
> >
> > Thank you for catching the struct padding risk. You are completely
> > right—Patch 7 (it87.c) would trigger a KMSAN uninit-value warning due
> > to the kmemdup() copy in platform_device_add_data(). I will drop that
> > patch entirely.
> >
> > I have audited the other six drivers in this series and verified that
> > their variables are never passed to memcmp(), kmemdup(), or hashed, so
> > the = {} initialization is perfectly safe there.
> >
> > While this does not fix an active bug, the goal is to follow a cleanup
> > pattern  recently discussed for the IIO subsystem [1],[2]
> > 1.Better performance: It removes the need for an extra function call.
> > Instead, the compiler clears the memory directly and more efficiently.
> > 2.Safer code: It prevents accidental memory leaks that happen when
> > developers make a typo in the sizeof() calculation.
> >
> > Would you be open to a v2 that includes just the six safe patches to
> > modernize these initializations?
> >
>
> Not really. I would not mind if there was a safe means to initialize
> a data structure without risking holes and without memset(). In the
> absence of that I rather play safe than sorry (and apparently we have
> a different opinion about the definition of "safe").
>
> Guenter
>
> > [1] https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
> > [2] https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
> >
> > Thanks for your time and guidance,
> >
> > Thanks & Regards,
> > Manish
> >
> > On Sun, Jun 7, 2026 at 9:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 5/30/26 15:13, Manish Baing wrote:
> >>> Hi all,
> >>>
> >>> This patch series cleans up memory initialization across several
> >>> hardware monitoring (hwmon) drivers by replacing explicit memset() calls
> >>> with empty brace initialization (= {}).
> >>>
> >>> Following similar cleanups in the IIO subsystem [1], this series updates
> >>> these drivers to stop using memset() for stack memory initialization.
> >>> As noted in those discussions [2], using empty brace initialization (= {})
> >>> is the preferred approach.
> >>>
> >>> Beyond simple replacements, a few drivers (nct6683, nct6775-platform, it87)
> >>> were using memset() inside a for-loop. To fix this, the variable
> >>> declarationwas moved directly inside the loop and zero-initialized there.
> >>> This safely resets the data on every iteration and makes the code much
> >>> cleaner.
> >>>
> >>> Testing:
> >>> - Compiled all modified files using `make W=1` with no warnings or errors.
> >>>
> >>> [1]: https://lore.kernel.org/all/20250611-iio-zero-init-stack-with-instead-of-memset-v1-0-ebb2d0a24302@baylibre.com/
> >>> [2]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/
> >>
> >> That discussion does not fully address a problem I had seen previously,
> >> where {} did _not_ zero-fill all holes, causing subsequent memcmp()
> >> failures on affected data structures. It took a lot a lot of debugging
> >> to find and fix that problem. Given that, I am not inclined to accept
> >> this series unless someone convinces me that it fixes an actual problem
> >> _and_ that each and every instance of the changes is not used in a
> >> subsequent memcmp().
> >>
> >> Guenter
> >>
> >
>