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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 10 Mar 2021 10:37:16 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Douglas Anderson <dianders@...omium.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Rob Clark <robdclark@...il.com>,
        Jordan Crouse <jcrouse@...eaurora.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>, swboyd@...omium.org,
        linux-arm-msm@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Akhil P Oommen <akhilpo@...eaurora.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] nvmem: core: Add functions to make number reading
 easy



On 06/03/2021 00:26, Douglas Anderson wrote:
> Sometimes the clients of nvmem just want to get a number out of
> nvmem. They don't want to think about exactly how many bytes the nvmem
> cell took up. They just want the number. Let's make it easy.
> 
> In general this concept is useful because nvmem space is precious and
> usually the fewest bits are allocated that will hold a given value on
> a given system. However, even though small numbers might be fine on
> one system that doesn't mean that logically the number couldn't be
> bigger. Imagine nvmem containing a max frequency for a component. On
> one system perhaps that fits in 16 bits. On another system it might
> fit in 32 bits. The code reading this number doesn't care--it just
> wants the number.
> 
> We'll provide two functions: nvmem_cell_read_variable_le_u32() and
> nvmem_cell_read_variable_le_u64().
> 
> Comparing these to the existing functions like nvmem_cell_read_u32():
> * These new functions have no problems if the value was stored in
>    nvmem in fewer bytes. It's OK to use these function as long as the
>    value stored will fit in 32-bits (or 64-bits).
> * These functions avoid problems that the earlier APIs had with bit
>    offsets. For instance, you can't use nvmem_cell_read_u32() to read a
>    value has nbits=32 and bit_offset=4 because the nvmem cell must be
>    at least 5 bytes big to hold this value. The new API accounts for
>    this and works fine.
> * These functions make it very explicit that they assume that the
>    number was stored in little endian format. The old functions made
>    this assumption whenever bit_offset was non-zero (see
>    nvmem_shift_read_buffer_in_place()) but didn't whenever the
>    bit_offset was zero.
> 
> NOTE: it's assumed that we don't need an 8-bit or 16-bit version of
> this function. The 32-bit version of the function can be used to read
> 8-bit or 16-bit data.
> 
> At the moment, I'm only adding the "unsigned" versions of these
> functions, but if it ends up being useful someone could add a "signed"
> version that did 2's complement sign extension.
> 
> At the moment, I'm only adding the "little endian" versions of these
> functions. Adding the "big endian" version would require adding "big
> endian" support to nvmem_shift_read_buffer_in_place().
> 
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
> This is a logical follow-up to:
>    https://lore.kernel.org/r/20210227002603.3260599-1-dianders@chromium.org/
> ...but since it doesn't really share any of the same patches I'm not
> marking it as a v2.
> 
>   drivers/nvmem/core.c           | 95 ++++++++++++++++++++++++++++++++++
>   include/linux/nvmem-consumer.h |  4 ++
>   2 files changed, 99 insertions(+)
> 

This patch as it is LGTM.

If you plan to take this via other trees, here is

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>

--srini

> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index a5ab1e0c74cf..635e3131eb5f 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -1606,6 +1606,101 @@ int nvmem_cell_read_u64(struct device *dev, const char *cell_id, u64 *val)
>   }
>   EXPORT_SYMBOL_GPL(nvmem_cell_read_u64);
>   
> +static void *nvmem_cell_read_variable_common(struct device *dev,
> +					     const char *cell_id,
> +					     size_t max_len, size_t *len)
> +{
> +	struct nvmem_cell *cell;
> +	int nbits;
> +	void *buf;
> +
> +	cell = nvmem_cell_get(dev, cell_id);
> +	if (IS_ERR(cell))
> +		return cell;
> +
> +	nbits = cell->nbits;
> +	buf = nvmem_cell_read(cell, len);
> +	nvmem_cell_put(cell);
> +	if (IS_ERR(buf))
> +		return buf;
> +
> +	/*
> +	 * If nbits is set then nvmem_cell_read() can significantly exaggerate
> +	 * the length of the real data. Throw away the extra junk.
> +	 */
> +	if (nbits)
> +		*len = DIV_ROUND_UP(nbits, 8);
> +
> +	if (*len > max_len) {
> +		kfree(buf);
> +		return ERR_PTR(-ERANGE);
> +	}
> +
> +	return buf;
> +}
> +
> +/**
> + * nvmem_cell_read_variable_le_u32() - Read up to 32-bits of data as a little endian number.
> + *
> + * @dev: Device that requests the nvmem cell.
> + * @cell_id: Name of nvmem cell to read.
> + * @val: pointer to output value.
> + *
> + * Return: 0 on success or negative errno.
> + */
> +int nvmem_cell_read_variable_le_u32(struct device *dev, const char *cell_id,
> +				    u32 *val)
> +{
> +	size_t len;
> +	u8 *buf;
> +	int i;
> +
> +	buf = nvmem_cell_read_variable_common(dev, cell_id, sizeof(*val), &len);
> +	if (IS_ERR(buf))
> +		return PTR_ERR(buf);
> +
> +	/* Copy w/ implicit endian conversion */
> +	*val = 0;
> +	for (i = 0; i < len; i++)
> +		*val |= buf[i] << (8 * i);
> +
> +	kfree(buf);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(nvmem_cell_read_variable_le_u32);
> +
> +/**
> + * nvmem_cell_read_variable_le_u64() - Read up to 64-bits of data as a little endian number.
> + *
> + * @dev: Device that requests the nvmem cell.
> + * @cell_id: Name of nvmem cell to read.
> + * @val: pointer to output value.
> + *
> + * Return: 0 on success or negative errno.
> + */
> +int nvmem_cell_read_variable_le_u64(struct device *dev, const char *cell_id,
> +				    u64 *val)
> +{
> +	size_t len;
> +	u8 *buf;
> +	int i;
> +
> +	buf = nvmem_cell_read_variable_common(dev, cell_id, sizeof(*val), &len);
> +	if (IS_ERR(buf))
> +		return PTR_ERR(buf);
> +
> +	/* Copy w/ implicit endian conversion */
> +	*val = 0;
> +	for (i = 0; i < len; i++)
> +		*val |= buf[i] << (8 * i);
> +
> +	kfree(buf);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(nvmem_cell_read_variable_le_u64);
> +
>   /**
>    * nvmem_device_cell_read() - Read a given nvmem device and cell
>    *
> diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> index 052293f4cbdb..923dada24eb4 100644
> --- a/include/linux/nvmem-consumer.h
> +++ b/include/linux/nvmem-consumer.h
> @@ -65,6 +65,10 @@ int nvmem_cell_read_u8(struct device *dev, const char *cell_id, u8 *val);
>   int nvmem_cell_read_u16(struct device *dev, const char *cell_id, u16 *val);
>   int nvmem_cell_read_u32(struct device *dev, const char *cell_id, u32 *val);
>   int nvmem_cell_read_u64(struct device *dev, const char *cell_id, u64 *val);
> +int nvmem_cell_read_variable_le_u32(struct device *dev, const char *cell_id,
> +				    u32 *val);
> +int nvmem_cell_read_variable_le_u64(struct device *dev, const char *cell_id,
> +				    u64 *val);
>   
>   /* direct nvmem device read/write interface */
>   struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ