[PATCH 05/13] nvmem: add mt6323 PMIC EFUSE driver

Roman Vivchar rva333 at protonmail.com
Tue May 5 09:24:41 PDT 2026


On Tuesday, May 5th, 2026 at 11:00 AM, Andy Shevchenko <andriy.shevchenko at intel.com> wrote:

> On Mon, May 04, 2026 at 09:24:57PM +0300, Roman Vivchar via B4 Relay wrote:
> 
> > Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
> > The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
> > thermal sensor calibration values.
> 
> Besides below comments, check for the similar issues that previous patches in
> the series have.
> 
> ...
> 
> > +#include <linux/device.h>
> 
> Not needed as platform_device.h implies this ("is this good or bad?" is a
> different story).
> 
> > +#include <linux/io.h>
> > +#include <linux/mfd/mt6323/registers.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/nvmem-provider.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/regmap.h>
> 
> Follow IWYU. At least missing types.h.
> 
> ...
> 
> > +struct mt6323_efuse {
> > +	struct regmap *regmap;
> > +};
> 
> Do you really need a custom wrapper data structure? Can't regmap be used
> directly?
> 
> ...
> 
> > +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> > +			     size_t bytes)
> > +{
> > +	struct mt6323_efuse *efuse = context;
> > +	u32 tmp;
> 
> > +	u16 *buf = val;
> 
> Really? CPU order all the time?
> 
> > +	int i, ret;
> 
> Why is 'i' signed?
> 
> > +	for (i = 0; i < bytes; i += 2) {
> 
> sizeof()?
> 
> And since 'i' is used only inside the loop
> 
> 	for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> 
> > +		ret = regmap_read(efuse->regmap,
> > +				  MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> > +		if (ret)
> > +			return ret;
> > +		buf[i / 2] = tmp;
> > +	}
> 
> + blank line.
> 
> Isn't this reimplementation of bulk read? Why the latter may not be used?

Yes, but the PWRAP (the regmap which the driver uses) doesn't support read
callback, only reg_read is implemented in the driver.
It hits the map->cache_type == REGCACHE_NONE in the regmap_read_raw, and falls
for the !map->read check, so regmap_bulk_read neither the regmap_read_raw
can be used.

Technically the PMIC is not continuous address space, but rather non-MMIO FSM,
so it makes sense to not implement the read callback. I guess the custom
implementation is fine then?

All other suggestions will be applied for v2.

> 
> > +	return 0;
> > +}
> 
> ...
> 
> > +static const struct of_device_id mt6323_efuse_of_match[] = {
> > +	{ .compatible = "mediatek,mt6323-efuse" },
> > +	{ /* sentinel */ },
> 
> Having trailing comma in the terminator is nonsense. Do we expect anything
> behind it?
> 
> > +};
> 
> --
> With Best Regards,
> Andy Shevchenko
> 
> 
>

Best regards,
Roman



More information about the linux-arm-kernel mailing list