linux-stable.git/drivers/nvmem/core.c, branch linux-6.10.y

nvmem: Fix return type of devm_nvmem_device_get() in kerneldoc

2024-09-12T09:13:07+00:00

commit c69f37f6559a8948d70badd2b179db7714dedd62 upstream.

devm_nvmem_device_get() returns an nvmem device, not an nvmem cell.

Fixes: e2a5402ec7c6d044 ("nvmem: Add nvmem_device based consumer apis.")
Cc: stable 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20240902142510.71096-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: limit cell sysfs permissions to main attribute ones

2024-07-03T14:37:51+00:00

The cell sysfs attribute should not provide more access to the nvmem
data than the main attribute itself.
For example if nvme_config::root_only was set, the cell attribute
would still provide read access to everybody.

Mask out permissions not available on the main attribute.

Fixes: 0331c611949f ("nvmem: core: Expose cells through sysfs")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20240628113704.13742-5-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: only change name to fram for current attribute

2024-07-03T14:37:51+00:00

bin_attr_nvmem_eeprom_compat is the template from which all future
compat attributes are created.
Changing it means to change all subsquent compat attributes, too.

Instead only use the "fram" name for the currently registered attribute.

Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20240628113704.13742-4-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: switch to use device_add_groups()

2024-05-03T05:26:38+00:00

devm_device_add_groups() is being removed from the kernel, so move the
nvmem driver to use device_add_groups() instead.  The logic is
identical, when the device is removed the driver core will properly
clean up and remove the groups, and the memory used by the attribute
groups will be freed because it was created with dev_* calls, so this is
functionally identical overall.

Cc: Srinivas Kandagatla 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20240430084921.33387-7-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: Print error on wrong bits DT property

2024-03-07T20:21:53+00:00

The algorithms in nvmem core are built with the constraint that
bit_offset < 8. If bit_offset is greater the results are wrong. Print an
error if the devicetree 'bits' property is outside of the valid range
and abort parsing.

Signed-off-by: Markus Schneider-Pargmann 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20240224114516.86365-12-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: include bit index in cell sysfs file name

2024-02-14T15:28:16+00:00

Creating sysfs files for all Cells caused a boot failure for linux-6.8-rc1 on
Apple M1, which (in downstream dts files) has multiple nvmem cells that use the
same byte address. This causes the device probe to fail with

[    0.605336] sysfs: cannot create duplicate filename '/devices/platform/soc@200000000/2922bc000.efuse/apple_efuses_nvmem0/cells/efuse@a10'
[    0.605347] CPU: 7 PID: 1 Comm: swapper/0 Tainted: G S                 6.8.0-rc1-arnd-5+ #133
[    0.605355] Hardware name: Apple Mac Studio (M1 Ultra, 2022) (DT)
[    0.605362] Call trace:
[    0.605365]  show_stack+0x18/0x2c
[    0.605374]  dump_stack_lvl+0x60/0x80
[    0.605383]  dump_stack+0x18/0x24
[    0.605388]  sysfs_warn_dup+0x64/0x80
[    0.605395]  sysfs_add_bin_file_mode_ns+0xb0/0xd4
[    0.605402]  internal_create_group+0x268/0x404
[    0.605409]  sysfs_create_groups+0x38/0x94
[    0.605415]  devm_device_add_groups+0x50/0x94
[    0.605572]  nvmem_populate_sysfs_cells+0x180/0x1b0
[    0.605682]  nvmem_register+0x38c/0x470
[    0.605789]  devm_nvmem_register+0x1c/0x6c
[    0.605895]  apple_efuses_probe+0xe4/0x120
[    0.606000]  platform_probe+0xa8/0xd0

As far as I can tell, this is a problem for any device with multiple cells on
different bits of the same address. Avoid the issue by changing the file name
to include the first bit number.

Fixes: 0331c611949f ("nvmem: core: Expose cells through sysfs")
Link: https://github.com/AsahiLinux/linux/blob/bd0a1a7d4/arch/arm64/boot/dts/apple/t600x-dieX.dtsi#L156
Cc:  
Cc: Miquel Raynal 
Cc: Rafał Miłecki 
Cc: Chen-Yu Tsai 
Cc: Srinivas Kandagatla 
Cc: Greg Kroah-Hartman 
Cc:  
Cc: Sven Peter 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Eric Curtin 
Reviewed-by: Miquel Raynal 
Link: https://lore.kernel.org/r/20240209163454.98051-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: add nvmem_dev_size() helper

2024-01-04T16:01:13+00:00

This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).

Signed-off-by: Rafał Miłecki 
Reviewed-by: Miquel Raynal 
Link: https://lore.kernel.org/r/20231221173421.13737-2-zajec5@gmail.com
Signed-off-by: Greg Kroah-Hartman

nvmem: drop nvmem_layout_get_match_data()

2024-01-04T16:01:13+00:00

Thanks for layouts refactoring we now have "struct device" associated
with layout. Also its OF pointer points directly to the "nvmem-layout"
DT node.

All it takes to get match data is a generic of_device_get_match_data().

Signed-off-by: Rafał Miłecki 
Reviewed-by: Miquel Raynal 
Reviewed-by: Michael Walle 
Link: https://lore.kernel.org/r/20231219120104.3422-2-zajec5@gmail.com
Signed-off-by: Greg Kroah-Hartman

nvmem: layouts: refactor .add_cells() callback arguments

2024-01-04T16:01:13+00:00

Simply pass whole "struct nvmem_layout" instead of single variables.
There is nothing in "struct nvmem_layout" that we have to hide from
layout drivers. They also access it during .probe() and .remove().

Thanks to this change:

1. API gets more consistent
   All layouts drivers callbacks get the same argument

2. Layouts get correct device
   Before this change NVMEM core code was passing NVMEM device instead
   of layout device. That resulted in:
   * Confusing prints
   * Calling devm_*() helpers on wrong device
   * Helpers like of_device_get_match_data() dereferencing NULLs

3. It gets possible to get match data
   First of all nvmem_layout_get_match_data() requires passing "struct
   nvmem_layout" which .add_cells() callback didn't have before this. It
   doesn't matter much as it's rather useless now anyway (and will be
   dropped).
   What's more important however is that of_device_get_match_data() can
   be used now thanks to owning a proper device pointer.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Miquel Raynal 
Reviewed-by: Michael Walle 
Link: https://lore.kernel.org/r/20231219120104.3422-1-zajec5@gmail.com
Signed-off-by: Greg Kroah-Hartman

nvmem: core: Expose cells through sysfs

2023-12-15T12:30:08+00:00

The binary content of nvmem devices is available to the user so in the
easiest cases, finding the content of a cell is rather easy as it is
just a matter of looking at a known and fixed offset. However, nvmem
layouts have been recently introduced to cope with more advanced
situations, where the offset and size of the cells is not known in
advance or is dynamic. When using layouts, more advanced parsers are
used by the kernel in order to give direct access to the content of each
cell, regardless of its position/size in the underlying
device. Unfortunately, these information are not accessible by users,
unless by fully re-implementing the parser logic in userland.

Let's expose the cells and their content through sysfs to avoid these
situations. Of course the relevant NVMEM sysfs Kconfig option must be
enabled for this support to be available.

Not all nvmem devices expose cells. Indeed, the .bin_attrs attribute
group member will be filled at runtime only when relevant and will
remain empty otherwise. In this case, as the cells attribute group will
be empty, it will not lead to any additional folder/file creation.

Exposed cells are read-only. There is, in practice, everything in the
core to support a write path, but as I don't see any need for that, I
prefer to keep the interface simple (and probably safer). The interface
is documented as being in the "testing" state which means we can later
add a write attribute if though relevant.

Signed-off-by: Miquel Raynal 
Tested-by: Rafał Miłecki 
Tested-by: Chen-Yu Tsai 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman