linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Michael Walle" <michael@walle.cc>,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
Date: Tue, 19 Dec 2023 08:55:17 +0100	[thread overview]
Message-ID: <20231219085517.4b6ec4fc@xps-13> (raw)
In-Reply-To: <13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>

Hi Rafał,

zajec5@gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:

> On 18.12.2023 15:21, Miquel Raynal wrote:
> > Hi Rafał,
> > 
> > zajec5@gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
> >   
> >> From: Rafał Miłecki <rafal@milecki.pl>
> >>
> >> This patch moves all generic (NVMEM devices independent) code from NVMEM
> >> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
> >> code on top of it.
> >>
> >> Thanks to proper layout it's possible to support U-Boot env data stored
> >> on any kind of NVMEM device.
> >>
> >> For backward compatibility with old DT bindings we need to keep old
> >> NVMEM device driver functional. To avoid code duplication a parsing
> >> function is exported and reused in it.
> >>
> >> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> >> ---  
> > 
> > I have a couple of comments about the original driver which gets
> > copy-pasted in the new layout driver, maybe you could clean these
> > (the memory leak should be fixed before the migration so it can be
> > backported easily, the others are just style so it can be done after, I
> > don't mind).
> > 
> > ...
> >   
> >> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
> >> +		     enum u_boot_env_format format)
> >> +{
> >> +	size_t crc32_data_offset;
> >> +	size_t crc32_data_len;
> >> +	size_t crc32_offset;
> >> +	size_t data_offset;
> >> +	size_t data_len;
> >> +	size_t dev_size;
> >> +	uint32_t crc32;
> >> +	uint32_t calc;
> >> +	uint8_t *buf;
> >> +	int bytes;
> >> +	int err;
> >> +
> >> +	dev_size = nvmem_dev_size(nvmem);
> >> +
> >> +	buf = kcalloc(1, dev_size, GFP_KERNEL);  
> > 
> > Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?  
> 
> I used kcalloc() initially as I didn't need buffer to be zeroed.

I think kcalloc() initializes the memory to zero.
https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L659

If you don't need it you can switch to kmalloc() instead, I don't mind,
but kcalloc() is meant to be used with arrays, I don't see the point of
using kcalloc() in this case.

> 
> I see that memory-allocation.rst however says:
>  > And, to be on the safe side it's best to use routines that set memory to zero, like kzalloc().  
> 
> It's probably close to zero cost to zero that buffer so it could be kzalloc().
> 
> 
> >> +	if (!buf) {
> >> +		err = -ENOMEM;
> >> +		goto err_out;  
> > 
> > We could directly return ENOMEM here I guess.
> >   
> >> +	}
> >> +
> >> +	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
> >> +	if (bytes < 0)
> >> +		return bytes;
> >> +	else if (bytes != dev_size)
> >> +		return -EIO;  
> > 
> > Don't we need to free buf in the above cases?
> >   
> >> +	switch (format) {
> >> +	case U_BOOT_FORMAT_SINGLE:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_single, data);
> >> +		break;
> >> +	case U_BOOT_FORMAT_REDUNDANT:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_redundant, data);
> >> +		break;
> >> +	case U_BOOT_FORMAT_BROADCOM:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> >> +		break;
> >> +	}
> >> +	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));  
> > 
> > Looks a bit convoluted, any chances we can use intermediate variables
> > to help decipher this?
> >   
> >> +	crc32_data_len = dev_size - crc32_data_offset;
> >> +	data_len = dev_size - data_offset;
> >> +
> >> +	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
> >> +	if (calc != crc32) {
> >> +		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
> >> +		err = -EINVAL;
> >> +		goto err_kfree;
> >> +	}
> >> +
> >> +	buf[dev_size - 1] = '\0';
> >> +	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
> >> +	if (err)
> >> +		dev_err(dev, "Failed to add cells: %d\n", err);  
> > 
> > Please drop this error message, the only reason for which the function
> > call would fail is apparently an ENOMEM case.
> >   
> >> +
> >> +err_kfree:
> >> +	kfree(buf);
> >> +err_out:
> >> +	return err;
> >> +}
> >> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
> >> +
> >> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
> >> +{
> >> +	const struct of_device_id *match;
> >> +	struct device_node *layout_np;
> >> +	enum u_boot_env_format format;
> >> +
> >> +	layout_np = of_nvmem_layout_get_container(nvmem);
> >> +	if (!layout_np)
> >> +		return -ENOENT;
> >> +
> >> +	match = of_match_node(u_boot_env_of_match_table, layout_np);
> >> +	if (!match)
> >> +		return -ENOENT;
> >> +
> >> +	format = (uintptr_t)match->data;  
> > 
> > In the core there is currently an unused helper called
> > nvmem_layout_get_match_data() which does that. I think the original
> > intent of this function was to be used in this driver, so depending on
> > your preference, can you please either use it or remove it?  
> 
> The problem is that nvmem_layout_get_match_data() uses:
> layout->dev.driver

I'm surprised .driver is unset. Well anyway, please either fix the core
helper and use it or drop the core helper, because we have no user for
it otherwise?

> It doesn't work with layouts driver (since refactoring?) as driver is
> NULL. That results in NULL pointer dereference when trying to reach
> of_match_table.
> 
> That is why I used u_boot_env_of_match_table directly.
> 
> If you know how to fix nvmem_layout_get_match_data() that would be
> great. Do we need driver_register() somewhere in NVMEM core?
> 


Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2023-12-19  7:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18 13:37 [PATCH 1/4] dt-bindings: nvmem: layouts: add U-Boot environment variables layout Rafał Miłecki
2023-12-18 13:37 ` [PATCH 2/4] nvmem: core: add nvmem_dev_size() helper Rafał Miłecki
2023-12-18 14:03   ` Miquel Raynal
2023-12-18 13:37 ` [PATCH 3/4] nvmem: u-boot-env: use more nvmem subsystem helpers Rafał Miłecki
2023-12-18 14:02   ` Miquel Raynal
2023-12-18 13:37 ` [PATCH 4/4] nvmem: layouts: add U-Boot env layout Rafał Miłecki
2023-12-18 14:21   ` Miquel Raynal
2023-12-18 22:10     ` Rafał Miłecki
2023-12-19  7:55       ` Miquel Raynal [this message]
2023-12-19  9:55         ` Rafał Miłecki
2023-12-19 10:10           ` Rafał Miłecki
2023-12-18 14:48 ` [PATCH 1/4] dt-bindings: nvmem: layouts: add U-Boot environment variables layout Rob Herring
2023-12-18 22:13   ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231219085517.4b6ec4fc@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=rafal@milecki.pl \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).