linux

nvmem: use SPDX license identifiers Use SPDX license identiefiers to core nvmem files and remove GPL 2.0 license boilerplate. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:20 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add support for the write-protect pin The write-protect pin handling looks like a standard property that could benefit other users if available in the core nvmem framework. Instead of modifying all the memory drivers to check this pin, make the NVMEM subsystem check if the write-protect GPIO being passed through the nvmem_config or defined in the device tree and pull it low whenever writing to the memory. There was a suggestion for introducing the gpiodesc from pdata, but as pdata is already removed it could be replaced by adding it to nvmem_config. Reference: https://lists.96boards.org/pipermail/dev/2018-August/001056.html Signed-off-by: Khouloud Touil <ktouil@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

2020-01-07 10:29:19 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Create a header for internal sharing Before adding all the NVMEM layout bus infrastructure to the core, let's move the main nvmem_device structure in an internal header, only available to the core. This way all the additional code can be added in a dedicated file in order to keep the current core file tidy. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:29 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: add per-cell post processing Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:24 +01:00

nvmem: core: provide own priv pointer in post process callback It doesn't make any more sense to have a opaque pointer set up by the nvmem device. Usually, the layout isn't associated with a particular nvmem device. Instead, let the caller who set the post process callback provide the priv pointer. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-21-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:28 +01:00

nvmem: core: fix regression in of_nvmem_cell_get() NVMEM DT support seems to be totally broken after commit e888d445ac33 ("nvmem: resolve cells from DT at registration time") Fix this! Index used in of_nvmem_cell_get() to find cell is specific to consumer, It can not be used for searching the cell in provider. Use device_node instead of this to find the matching cell in device tree case. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-06 15:41:41 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: core: Add support for keepout regions Introduce support into the nvmem core for arrays of register ranges that should not result in actual device access. For these regions a constant byte (repeated) is returned instead on read, and writes are quietly ignored and returned as successful. This is useful for instance if certain efuse regions are protected from access by Linux because they contain secret info to another part of the system (like an integrated modem). Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20201127102837.19366-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-11-27 10:28:34 +00:00

nvmem: ensure sysfs writes handle write-protect pin Commit 2a127da461a9 ("nvmem: add support for the write-protect pin") added support for handling write-protect pins to the nvmem core, and Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support") retrofitted the at24 driver to use this support. These changes broke write() on the nvmem sysfs attribute for eeproms which utilize a write-protect pin, as the write callback invokes the nvmem device's reg_write callback directly which no longer handles changing the state of the write-protect pin. Change the read and write callbacks for the sysfs attribute to invoke nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than calling reg_read/reg_write directly. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-05-11 15:50:41 +01:00

nvmem: core: Add support for keepout regions Introduce support into the nvmem core for arrays of register ranges that should not result in actual device access. For these regions a constant byte (repeated) is returned instead on read, and writes are quietly ignored and returned as successful. This is useful for instance if certain efuse regions are protected from access by Linux because they contain secret info to another part of the system (like an integrated modem). Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20201127102837.19366-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-11-27 10:28:34 +00:00

nvmem: ensure sysfs writes handle write-protect pin Commit 2a127da461a9 ("nvmem: add support for the write-protect pin") added support for handling write-protect pins to the nvmem core, and Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support") retrofitted the at24 driver to use this support. These changes broke write() on the nvmem sysfs attribute for eeproms which utilize a write-protect pin, as the write callback invokes the nvmem device's reg_write callback directly which no longer handles changing the state of the write-protect pin. Change the read and write callbacks for the sysfs attribute to invoke nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than calling reg_read/reg_write directly. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-05-11 15:50:41 +01:00

nvmem: core: Add support for keepout regions Introduce support into the nvmem core for arrays of register ranges that should not result in actual device access. For these regions a constant byte (repeated) is returned instead on read, and writes are quietly ignored and returned as successful. This is useful for instance if certain efuse regions are protected from access by Linux because they contain secret info to another part of the system (like an integrated modem). Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20201127102837.19366-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-11-27 10:28:34 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: prepare basics for FRAM support Added enum and string for FRAM (ferroelectric RAM) to expose it as file named "fram". Added documentation of sysfs file. Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz> Link: https://lore.kernel.org/r/20210611094601.95131-2-jiri.prchal@aksignal.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 11:45:58 +02:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Use sysfs_emit() for type attribute Use sysfs_emit() instead of sprintf() to follow best practice per Documentation/filesystems/sysfs.rst " show() should only use sysfs_emit()... " Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-15-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:51 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Implement force_ro sysfs attribute Implement "force_ro" sysfs attribute to allow users to set read-write devices as read-only and back to read-write from userspace. The choice of the name is based on MMC core 'force_ro' attribute. This solves a situation where an AT24 I2C EEPROM with GPIO based nWP signal may have to be occasionally updated. Such I2C EEPROM device is usually set as read-only during most of the regular system operation, but in case it has to be updated in a controlled manner, it could be unlocked using this new "force_ro" sysfs attribute and then re-locked again. The "read-only" DT property and config->read_only configuration is respected and is used to set default state of the device, read-only or read-write, for devices which do implement .reg_write function. For devices which do not implement .reg_write function, the device is unconditionally read-only and the "force_ro" attribute is not visible. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:52 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Implement force_ro sysfs attribute Implement "force_ro" sysfs attribute to allow users to set read-write devices as read-only and back to read-write from userspace. The choice of the name is based on MMC core 'force_ro' attribute. This solves a situation where an AT24 I2C EEPROM with GPIO based nWP signal may have to be occasionally updated. Such I2C EEPROM device is usually set as read-only during most of the regular system operation, but in case it has to be updated in a controlled manner, it could be unlocked using this new "force_ro" sysfs attribute and then re-locked again. The "read-only" DT property and config->read_only configuration is respected and is used to set default state of the device, read-only or read-write, for devices which do implement .reg_write function. For devices which do not implement .reg_write function, the device is unconditionally read-only and the "force_ro" attribute is not visible. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:52 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Use kobj_to_dev() instead of container_of() Use kobj_to_dev() instead of container_of() Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:35 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Enforce nvmem stride in the sysfs interface The 'struct nvmem_config' has a stride attribute that specifies the needed alignment for accesses into the nvmem. This is used in nvmem_cell_info_to_nvmem_cell() but not in the sysfs read/write functions. If the alignment is important in one place it's important everywhere, so let's add enforcement. For now we'll consider it totally invalid to access with the wrong alignment. We could relax this in the read case where we could just read some extra bytes and throw them away. Relaxing it in the write case seems harder (and less safe?) since we'd have to read some data first and then write it back. To keep it symmetric we'll just disallow it in both cases. Reported-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Tested-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:54 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: ensure sysfs writes handle write-protect pin Commit 2a127da461a9 ("nvmem: add support for the write-protect pin") added support for handling write-protect pins to the nvmem core, and Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support") retrofitted the at24 driver to use this support. These changes broke write() on the nvmem sysfs attribute for eeproms which utilize a write-protect pin, as the write callback invokes the nvmem device's reg_write callback directly which no longer handles changing the state of the write-protect pin. Change the read and write callbacks for the sysfs attribute to invoke nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than calling reg_read/reg_write directly. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-05-11 15:50:41 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Use kobj_to_dev() instead of container_of() Use kobj_to_dev() instead of container_of() Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:35 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Enforce nvmem stride in the sysfs interface The 'struct nvmem_config' has a stride attribute that specifies the needed alignment for accesses into the nvmem. This is used in nvmem_cell_info_to_nvmem_cell() but not in the sysfs read/write functions. If the alignment is important in one place it's important everywhere, so let's add enforcement. For now we'll consider it totally invalid to access with the wrong alignment. We could relax this in the read case where we could just read some extra bytes and throw them away. Relaxing it in the write case seems harder (and less safe?) since we'd have to read some data first and then write it back. To keep it symmetric we'll just disallow it in both cases. Reported-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Tested-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:54 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Check read_only flag for force_ro in bin_attr_nvmem_write() The bin_attr_nvmem_write() must check the read_only flag and block writes on read-only devices, now that a nvmem device can be switched between read-write and read-only mode at runtime using the force_ro attribute. Add the missing check. Fixes: 9d7eb234ac7a ("nvmem: core: Implement force_ro sysfs attribute") Cc: Stable@vger.kernel.org Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241030140253.40445-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-10-30 14:02:53 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: ensure sysfs writes handle write-protect pin Commit 2a127da461a9 ("nvmem: add support for the write-protect pin") added support for handling write-protect pins to the nvmem core, and Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support") retrofitted the at24 driver to use this support. These changes broke write() on the nvmem sysfs attribute for eeproms which utilize a write-protect pin, as the write callback invokes the nvmem device's reg_write callback directly which no longer handles changing the state of the write-protect pin. Change the read and write callbacks for the sysfs attribute to invoke nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than calling reg_read/reg_write directly. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-05-11 15:50:41 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

sysfs: treewide: constify attribute callback of bin_is_visible() The is_bin_visible() callbacks should not modify the struct bin_attribute passed as argument. Enforce this by marking the argument as const. As there are not many callback implementers perform this change throughout the tree at once. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Ira Weiny <ira.weiny@intel.com> Acked-by: Krzysztof Wilczyński <kw@linux.com> Link: https://lore.kernel.org/r/20241103-sysfs-const-bin_attr-v2-5-71110628844c@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-11-03 17:03:34 +00:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: Use kobj_to_dev() instead of container_of() Use kobj_to_dev() instead of container_of() Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:35 +01:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: calculate bin_attribute size through bin_size() Stop abusing the is_bin_visible() callback to calculate the attribute size. Instead use the new, dedicated bin_size() one. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Krzysztof Wilczyński <kw@linux.com> Link: https://lore.kernel.org/r/20241103-sysfs-const-bin_attr-v2-4-71110628844c@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-11-03 17:03:33 +00:00

nvmem: core: Implement force_ro sysfs attribute Implement "force_ro" sysfs attribute to allow users to set read-write devices as read-only and back to read-write from userspace. The choice of the name is based on MMC core 'force_ro' attribute. This solves a situation where an AT24 I2C EEPROM with GPIO based nWP signal may have to be occasionally updated. Such I2C EEPROM device is usually set as read-only during most of the regular system operation, but in case it has to be updated in a controlled manner, it could be unlocked using this new "force_ro" sysfs attribute and then re-locked again. The "read-only" DT property and config->read_only configuration is respected and is used to set default state of the device, read-only or read-write, for devices which do implement .reg_write function. For devices which do not implement .reg_write function, the device is unconditionally read-only and the "force_ro" attribute is not visible. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:52 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: calculate bin_attribute size through bin_size() Stop abusing the is_bin_visible() callback to calculate the attribute size. Instead use the new, dedicated bin_size() one. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Krzysztof Wilczyński <kw@linux.com> Link: https://lore.kernel.org/r/20241103-sysfs-const-bin_attr-v2-4-71110628844c@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-11-03 17:03:33 +00:00

nvmem: core: Implement force_ro sysfs attribute Implement "force_ro" sysfs attribute to allow users to set read-write devices as read-only and back to read-write from userspace. The choice of the name is based on MMC core 'force_ro' attribute. This solves a situation where an AT24 I2C EEPROM with GPIO based nWP signal may have to be occasionally updated. Such I2C EEPROM device is usually set as read-only during most of the regular system operation, but in case it has to be updated in a controlled manner, it could be unlocked using this new "force_ro" sysfs attribute and then re-locked again. The "read-only" DT property and config->read_only configuration is respected and is used to set default state of the device, read-only or read-write, for devices which do implement .reg_write function. For devices which do not implement .reg_write function, the device is unconditionally read-only and the "force_ro" attribute is not visible. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:52 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: only change name to fram for current attribute 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 <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240628113704.13742-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-06-28 12:37:03 +01:00

nvmem: core: cleanup old eeprom compat entry attributes file permission are derived based on various configs for default nvmem sysfs file, reuse it to create the eeprom compat file too. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200417121306.23121-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-04-17 13:13:06 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: remove global nvmem_cells_group nvmem_cells_groups is a global variable that is also mutated. This is complicated and error-prone. Instead use a normal stack variable. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:47 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove global nvmem_cells_group nvmem_cells_groups is a global variable that is also mutated. This is complicated and error-prone. Instead use a normal stack variable. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:47 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: remove global nvmem_cells_group nvmem_cells_groups is a global variable that is also mutated. This is complicated and error-prone. Instead use a normal stack variable. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:47 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: include bit index in cell sysfs file name 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: <regressions@lists.linux.dev> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Rafał Miłecki <rafal@milecki.pl> Cc: Chen-Yu Tsai <wenst@chromium.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <asahi@lists.linux.dev> Cc: Sven Peter <sven@svenpeter.dev> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20240209163454.98051-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-02-09 16:34:54 +00:00

nvmem: core: limit cell sysfs permissions to main attribute ones 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 <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240628113704.13742-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-06-28 12:37:04 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: constify 'struct bin_attribute' The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Also adapt the dynamic sysfs cell logic to handle the const attributes. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230143035.265518-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:30:25 +00:00

nvmem: core: remove global nvmem_cells_group nvmem_cells_groups is a global variable that is also mutated. This is complicated and error-prone. Instead use a normal stack variable. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240705074852.423202-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-07-05 08:48:47 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Move nvmem_type_str array to its only user Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually using it. Move nvmem_type_str array to its only user to make a compiler happy: In file included from include/linux/rtc.h:18, from drivers/rtc/rtc-proc.c:15: include/linux/nvmem-provider.h:29:27: warning: 'nvmem_type_str' defined but not used [-Wunused-const-variable=] static const char * const nvmem_type_str[] = { ^~~~~~~~~~~~~~ Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Suggested-by: Joe Perches <joe@perches.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-30 11:53:24 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: switch to simpler IDA interface We don't need to specify any ranges when allocating IDs so we can switch to ida_alloc() and ida_free() instead of the ida_simple_ counterparts. ida_simple_get(ida, 0, 0, gfp) is equivalent to ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID larger than INT_MAX. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:36 +01:00

nvmem: release the write-protect pin Put the write-protect GPIO descriptor in nvmem_release() so that it can be automatically released when the associated device's reference count drops to 0. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Khouloud Touil <ktouil@baylibre.com> Cc: stable <stable@vger.kernel.org> [Bartosz: tweak the commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:50 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: core: fix regression in of_nvmem_cell_get() NVMEM DT support seems to be totally broken after commit e888d445ac33 ("nvmem: resolve cells from DT at registration time") Fix this! Index used in of_nvmem_cell_get() to find cell is specific to consumer, It can not be used for searching the cell in provider. Use device_node instead of this to find the matching cell in device tree case. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-06 15:41:41 +00:00

nvmem: core: fix memory abort in cleanup path nvmem_cell_info_to_nvmem_cell implementation has static allocation of name. nvmem_add_cells_from_of() call may return error and kfree name results in memory abort. Use kstrdup_const() and kfree_const calls for name alloc and free. Unable to handle kernel paging request at virtual address ffffffffffe44888 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 64k pages, 48-bit VAs, pgdp=00000000815d0000 [ffffffffffe44888] pgd=0000000081d30803, pud=0000000081d30803, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 43 Comm: kworker/2:1 Tainted Hardware name: quill (DT) Workqueue: events deferred_probe_work_func pstate: a0000005 (NzCv daif -PAN -UAO) pc : kfree+0x38/0x278 lr : nvmem_cell_drop+0x68/0x80 sp : ffff80001284f9d0 x29: ffff80001284f9d0 x28: ffff0001f677e830 x27: ffff800011b0b000 x26: ffff0001c36e1008 x25: ffff8000112ad000 x24: ffff8000112c9000 x23: ffffffffffffffea x22: ffff800010adc7f0 x21: ffffffffffe44880 x20: ffff800011b0b068 x19: ffff80001122d380 x18: ffffffffffffffff x17: 00000000d5cb4756 x16: 0000000070b193b8 x15: ffff8000119538c8 x14: 0720072007200720 x13: 07200720076e0772 x12: 07750762072d0765 x11: 0773077507660765 x10: 072f073007300730 x9 : 0730073207380733 x8 : 0000000000000151 x7 : 07660765072f0720 x6 : ffff0001c00e0f00 x5 : 0000000000000000 x4 : ffff0001c0b43800 x3 : ffff800011b0b068 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffffdfffe00000 Call trace: kfree+0x38/0x278 nvmem_cell_drop+0x68/0x80 nvmem_device_remove_all_cells+0x2c/0x50 nvmem_register.part.9+0x520/0x628 devm_nvmem_register+0x48/0xa0 tegra_fuse_probe+0x140/0x1f0 platform_drv_probe+0x50/0xa0 really_probe+0x108/0x348 driver_probe_device+0x58/0x100 __device_attach_driver+0x90/0xb0 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x138 device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0x74/0xb0 process_one_work+0x1e0/0x358 worker_thread+0x208/0x488 kthread+0x118/0x120 ret_from_fork+0x10/0x18 Code: d350feb5 f2dffbe0 aa1e03f6 8b151815 (f94006a0) ---[ end trace 49b1303c6b83198e ]--- Fixes: badcdff107cbf ("nvmem: Convert to using %pOFn instead of device_node.name") Signed-off-by: Bitan Biswas <bbiswas@nvidia.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200109104017.6249-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-01-09 10:40:17 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: fix possibly memleak when use nvmem_cell_info_to_nvmem_cell() Fix missing 'kfree_const(cell->name)' when call to nvmem_cell_info_to_nvmem_cell() in several places: * after nvmem_cell_info_to_nvmem_cell() failed during nvmem_add_cells() * during nvmem_device_cell_{read,write} when cell->name is kstrdup'ed() without calling kfree_const() at the end, but really there is no reason to do that 'dup, because the cell instance is allocated on the stack for some short period to be read/write without exposing it to the caller. So the new nvmem_cell_info_to_nvmem_cell_nodup() helper is introduced which is used to convert cell_info -> cell without name duplication as a lighweight version of nvmem_cell_info_to_nvmem_cell(). Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Link: https://lore.kernel.org/r/20200923204456.14032-1-vadym.kochan@plvision.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-23 23:44:56 +03:00

nvmem: core: add per-cell post processing Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:24 +01:00

nvmem: core: provide own priv pointer in post process callback It doesn't make any more sense to have a opaque pointer set up by the nvmem device. Usually, the layout isn't associated with a particular nvmem device. Instead, let the caller who set the post process callback provide the priv pointer. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-21-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:28 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: support passing DT node in cell info Some hardware may have NVMEM cells described in Device Tree using individual nodes. Let drivers pass such nodes to the NVMEM subsystem so they can be later used by NVMEM consumers. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220429162701.2222-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-04-29 17:26:46 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: fix possibly memleak when use nvmem_cell_info_to_nvmem_cell() Fix missing 'kfree_const(cell->name)' when call to nvmem_cell_info_to_nvmem_cell() in several places: * after nvmem_cell_info_to_nvmem_cell() failed during nvmem_add_cells() * during nvmem_device_cell_{read,write} when cell->name is kstrdup'ed() without calling kfree_const() at the end, but really there is no reason to do that 'dup, because the cell instance is allocated on the stack for some short period to be read/write without exposing it to the caller. So the new nvmem_cell_info_to_nvmem_cell_nodup() helper is introduced which is used to convert cell_info -> cell without name duplication as a lighweight version of nvmem_cell_info_to_nvmem_cell(). Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Link: https://lore.kernel.org/r/20200923204456.14032-1-vadym.kochan@plvision.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-23 23:44:56 +03:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: fix possibly memleak when use nvmem_cell_info_to_nvmem_cell() Fix missing 'kfree_const(cell->name)' when call to nvmem_cell_info_to_nvmem_cell() in several places: * after nvmem_cell_info_to_nvmem_cell() failed during nvmem_add_cells() * during nvmem_device_cell_{read,write} when cell->name is kstrdup'ed() without calling kfree_const() at the end, but really there is no reason to do that 'dup, because the cell instance is allocated on the stack for some short period to be read/write without exposing it to the caller. So the new nvmem_cell_info_to_nvmem_cell_nodup() helper is introduced which is used to convert cell_info -> cell without name duplication as a lighweight version of nvmem_cell_info_to_nvmem_cell(). Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Link: https://lore.kernel.org/r/20200923204456.14032-1-vadym.kochan@plvision.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-23 23:44:56 +03:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: fix possibly memleak when use nvmem_cell_info_to_nvmem_cell() Fix missing 'kfree_const(cell->name)' when call to nvmem_cell_info_to_nvmem_cell() in several places: * after nvmem_cell_info_to_nvmem_cell() failed during nvmem_add_cells() * during nvmem_device_cell_{read,write} when cell->name is kstrdup'ed() without calling kfree_const() at the end, but really there is no reason to do that 'dup, because the cell instance is allocated on the stack for some short period to be read/write without exposing it to the caller. So the new nvmem_cell_info_to_nvmem_cell_nodup() helper is introduced which is used to convert cell_info -> cell without name duplication as a lighweight version of nvmem_cell_info_to_nvmem_cell(). Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Link: https://lore.kernel.org/r/20200923204456.14032-1-vadym.kochan@plvision.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-23 23:44:56 +03:00

nvmem: core: add nvmem_add_one_cell() Add a new function to add exactly one cell. This will be used by the nvmem layout drivers to add custom cells. In contrast to the nvmem_add_cells(), this has the advantage that we don't have to assemble a list of cells on runtime. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:49 +00:00

drivers: nvmem: Export nvmem_add_cells() Not all platforms use device tree. It is useful to be able to add cells to a NVMEM device from code. Export nvmem_add_cells() so making this possible. This required changing the parameters a bit, so that just the cells and the number of cells are passed, not the whole nvmem config structure. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:06:56 +01:00

nvmem: make nvmem_add_cells() static Now we have new api nvmem_add/del_cell_table() we do not want users to use nvmem_add_cells() anymore. So mark it accordingly. I guess it was missed in original cleanup patch. This also fixes below warning: core.c:355:5: warning: no previous prototype for 'nvmem_add_cells' [-Wmissing-prototypes] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:26 -07:00

drivers: nvmem: Export nvmem_add_cells() Not all platforms use device tree. It is useful to be able to add cells to a NVMEM device from code. Export nvmem_add_cells() so making this possible. This required changing the parameters a bit, so that just the cells and the number of cells are passed, not the whole nvmem config structure. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:06:56 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: add nvmem_add_one_cell() Add a new function to add exactly one cell. This will be used by the nvmem layout drivers to add custom cells. In contrast to the nvmem_add_cells(), this has the advantage that we don't have to assemble a list of cells on runtime. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:49 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

drivers: nvmem: Export nvmem_add_cells() Not all platforms use device tree. It is useful to be able to add cells to a NVMEM device from code. Export nvmem_add_cells() so making this possible. This required changing the parameters a bit, so that just the cells and the number of cells are passed, not the whole nvmem config structure. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:06:56 +01:00

nvmem: core: add nvmem_add_one_cell() Add a new function to add exactly one cell. This will be used by the nvmem layout drivers to add custom cells. In contrast to the nvmem_add_cells(), this has the advantage that we don't have to assemble a list of cells on runtime. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:49 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: add nvmem_add_one_cell() Add a new function to add exactly one cell. This will be used by the nvmem layout drivers to add custom cells. In contrast to the nvmem_add_cells(), this has the advantage that we don't have to assemble a list of cells on runtime. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-16-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:49 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: Fix cell lookup when no cell is found If the cell list is not empty and nvmem_find_cell_by_node/name() is called for a cell that is not present in the list they will return an invalid pointer instead of NULL. This happen because list_for_each_entry() stop once it reach the list head again, but as the list head is not contained in a struct nvmem_cell the iteration variable then contains an invalid value. This is easily solved by using a variable to iterate over the list and one to return the cell found. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:02 +00:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: Fix cell lookup when no cell is found If the cell list is not empty and nvmem_find_cell_by_node/name() is called for a cell that is not present in the list they will return an invalid pointer instead of NULL. This happen because list_for_each_entry() stop once it reach the list head again, but as the list head is not contained in a struct nvmem_cell the iteration variable then contains an invalid value. This is easily solved by using a variable to iterate over the list and one to return the cell found. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:02 +00:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: Add support for keepout regions Introduce support into the nvmem core for arrays of register ranges that should not result in actual device access. For these regions a constant byte (repeated) is returned instead on read, and writes are quietly ignored and returned as successful. This is useful for instance if certain efuse regions are protected from access by Linux because they contain secret info to another part of the system (like an integrated modem). Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20201127102837.19366-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-11-27 10:28:34 +00:00

nvmem: core: add support for fixed cells *layout* This adds support for the "fixed-layout" NVMEM layout binding. It allows defining NVMEM cells in a layout DT node named "nvmem-layout". While NVMEM subsystem supports layout drivers it has been discussed that "fixed-layout" may actually be supperted internally. It's because: 1. It's a very basic layout 2. It allows sharing code with legacy syntax parsing 3. It's safer for soc_device_match() due to -EPROBE_DEFER 4. This will make the syntax transition easier Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Message-ID: <20230611140330.154222-26-srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-06-11 15:03:29 +01:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: add support for fixed cells *layout* This adds support for the "fixed-layout" NVMEM layout binding. It allows defining NVMEM cells in a layout DT node named "nvmem-layout". While NVMEM subsystem supports layout drivers it has been discussed that "fixed-layout" may actually be supperted internally. It's because: 1. It's a very basic layout 2. It allows sharing code with legacy syntax parsing 3. It's safer for soc_device_match() due to -EPROBE_DEFER 4. This will make the syntax transition easier Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Message-ID: <20230611140330.154222-26-srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-06-11 15:03:29 +01:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: skip child nodes not matching binding The nvmem cell binding applies to all eeprom child nodes matching "^.*@[0-9a-f]+$" without taking a compatible into account. Linux drivers, like at24, are even more extensive and assume _all_ at24 eeprom child nodes to be nvmem cells since e888d445ac33 ("nvmem: resolve cells from DT at registration time"). Since df5f3b6f5357 ("dt-bindings: nvmem: stm32: new property for data access"), the additionalProperties: True means it's Ok to have other properties as long as they don't match "^.*@[0-9a-f]+$". The barebox bootloader extends the MTD partitions binding to EEPROM and can fix up following device tree node: &eeprom { partitions { compatible = "fixed-partitions"; }; }; This is allowed binding-wise, but drivers using nvmem_register() like at24 will fail to parse because the function expects all child nodes to have a reg property present. This results in the whole EEPROM driver probe failing despite the device tree being correct. Fix this by skipping nodes lacking a reg property instead of returning an error. This effectively makes the drivers adhere to the binding because all nodes with a unit address must have a reg property and vice versa. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time"). Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210129171430.11328-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-01-29 17:14:30 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: add a missing of_node_put 'for_each_child_of_node' performs an of_node_get on each iteration, so a return from the middle of the loop requires an of_node_put. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Cc: <stable@vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611102321.11509-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 11:23:21 +01:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: core: Print error on wrong bits DT property 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 <msp@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240224114516.86365-12-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-02-24 11:45:16 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: Move and rename ->fixup_cell_info() This hook is meant to be used by any provider and instantiating a layout just for this is useless. Let's instead move this hook to the nvmem device and add it to the config structure to be easily shared by the providers. While at moving this hook, rename it ->fixup_dt_cell_info() to clarify its main intended purpose. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:31 +00:00

nvmem: core: allow to modify a cell before adding it Provide a way to modify a cell before it will get added. This is useful to attach a custom post processing hook via a layout. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-18-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:25 +01:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: core: add a missing of_node_put 'for_each_child_of_node' performs an of_node_get on each iteration, so a return from the middle of the loop requires an of_node_put. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Cc: <stable@vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611102321.11509-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 11:23:21 +01:00

nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of() Convert nvmem_add_cells_from_of() to use the new nvmem_add_one_cell(). This will remove duplicate code and it will make it possible to add a hook to a nvmem layout in between, which can change fields before the cell is finally added. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:50 +00:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: add support for fixed cells *layout* This adds support for the "fixed-layout" NVMEM layout binding. It allows defining NVMEM cells in a layout DT node named "nvmem-layout". While NVMEM subsystem supports layout drivers it has been discussed that "fixed-layout" may actually be supperted internally. It's because: 1. It's a very basic layout 2. It allows sharing code with legacy syntax parsing 3. It's safer for soc_device_match() due to -EPROBE_DEFER 4. This will make the syntax transition easier Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Message-ID: <20230611140330.154222-26-srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-06-11 15:03:29 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: layouts: refactor .add_cells() callback arguments 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 <rafal@milecki.pl> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20231219120104.3422-1-zajec5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-19 13:01:03 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Grammar fixes for help text It's "an unsigned" but "a U". Similarly, "an entry" but "a binary entry". While at it, also drop superfluous articles for negative and zero. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:56 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: validate nvmem config before parsing nvmem provider has to provide either reg_read/write, add a check to enforce this. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:51 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: remove spurious white space Remove a spurious white space in for the ida_alloc() call. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:41 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add a newline for readability Visibly separate the GPIO request from the previous operation in the code with a newline. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:48 +00:00

nvmem: core: initialise nvmem->id early The error path for wp_gpio attempts to free the IDA nvmem->id, but this has yet to be assigned, so will always be zero - leaking the ID allocated by ida_alloc(). Fix this by moving the initialisation of nvmem->id earlier. Fixes: f7d8d7dcd978 ("nvmem: fix memory leak in error path") Cc: stable@vger.kernel.org Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:08 +00:00

nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". Fixes: 5544e90c8126 ("nvmem: core: add error handling for dev_set_name") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [Srini: Fixed subject line and error code handing with wp_gpio while applying.] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:10 +00:00

nvmem: core: remove nvmem_config wp_gpio No one provides wp_gpio, so let's remove it to avoid issues with the nvmem core putting this gpio. Cc: stable@vger.kernel.org Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:09 +00:00

nvmem: add support for the write-protect pin The write-protect pin handling looks like a standard property that could benefit other users if available in the core nvmem framework. Instead of modifying all the memory drivers to check this pin, make the NVMEM subsystem check if the write-protect GPIO being passed through the nvmem_config or defined in the device tree and pull it low whenever writing to the memory. There was a suggestion for introducing the gpiodesc from pdata, but as pdata is already removed it could be replaced by adding it to nvmem_config. Reference: https://lists.96boards.org/pipermail/dev/2018-August/001056.html Signed-off-by: Khouloud Touil <ktouil@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

2020-01-07 10:29:19 +01:00

nvmem: fix memory leak in error path We need to free the ida mapping and nvmem struct if the write-protect GPIO lookup fails. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:49 +00:00

nvmem: core: fix return value Dan Carpenter points out that the return code was not set in commit 60c8b4aebd8e ("nvmem: core: fix cleanup after dev_set_name()"), but this is not the only issue - we also need to zero wp_gpio to prevent gpiod_put() being called on an error value. Fixes: 560181d3ace6 ("nvmem: core: fix cleanup after dev_set_name()") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:14 +00:00

nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". Fixes: 5544e90c8126 ("nvmem: core: add error handling for dev_set_name") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [Srini: Fixed subject line and error code handing with wp_gpio while applying.] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:10 +00:00

nvmem: fix memory leak in error path We need to free the ida mapping and nvmem struct if the write-protect GPIO lookup fails. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:49 +00:00

nvmem: add support for the write-protect pin The write-protect pin handling looks like a standard property that could benefit other users if available in the core nvmem framework. Instead of modifying all the memory drivers to check this pin, make the NVMEM subsystem check if the write-protect GPIO being passed through the nvmem_config or defined in the device tree and pull it low whenever writing to the memory. There was a suggestion for introducing the gpiodesc from pdata, but as pdata is already removed it could be replaced by adding it to nvmem_config. Reference: https://lists.96boards.org/pipermail/dev/2018-August/001056.html Signed-off-by: Khouloud Touil <ktouil@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

2020-01-07 10:29:19 +01:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: Move and rename ->fixup_cell_info() This hook is meant to be used by any provider and instantiating a layout just for this is useless. Let's instead move this hook to the nvmem device and add it to the config structure to be easily shared by the providers. While at moving this hook, rename it ->fixup_dt_cell_info() to clarify its main intended purpose. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:31 +00:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: set nvmem->owner to nvmem->dev->driver->owner if unset All nvmem drivers are supposed to set the owner field of struct nvmem_config, but this matches nvmem->dev->driver->owner. As far as I see in drivers/nvmem/ directory, all the drivers are the case. So, make nvmem_register() set the nvmem's owner to the associated driver's owner unless nvmem_config sets otherwise. Remove .owner settings in the drivers that are now redundant. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-10-21 01:57:42 +09:00

nvmem: core: let stride and word_size default to 1 If the caller doesn't set stride and/or word_size in struct nvmem_config then nvmem_register accepts this but we may face strange effects later due to both values being 0. Therefore use 1 as default for both values. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-12-15 14:06:05 +00:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: core: add root_only member to nvmem device struct As we are planning to move to use sysfs is_bin_visible callback, having root_only as part of nvmem_device will help decide correct permissions. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325122116.15096-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 12:21:15 +00:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: add type attribute Add a type attribute so userspace is able to know how the data is stored as this can help taking the correct decision when selecting which device to use. This will also help program display the proper warnings when burning fuses for example. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-30 11:53:20 +00:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: core: Add support for keepout regions Introduce support into the nvmem core for arrays of register ranges that should not result in actual device access. For these regions a constant byte (repeated) is returned instead on read, and writes are quietly ignored and returned as successful. This is useful for instance if certain efuse regions are protected from access by Linux because they contain secret info to another part of the system (like an integrated modem). Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20201127102837.19366-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-11-27 10:28:34 +00:00

nvmem: core: allow specifying of_node Until now, the of_node of the parent device is used. Some devices provide more than just the nvmem provider. To avoid name space clashes, add a way to allow specifying the nvmem cells in subnodes. Consider the following example: flash@0 { compatible = "jedec,spi-nor"; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; partition@0 { reg = <0x000000 0x010000>; }; }; otp { compatible = "user-otp"; #address-cells = <1>; #size-cells = <1>; serial-number@0 { reg = <0x0 0x8>; }; }; }; There the nvmem provider might be the MTD partition or the OTP region of the flash. Add a new config->of_node parameter, which if set, will be used instead of the parent's of_node. Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210424110608.15748-2-michael@walle.cc

2021-04-24 13:06:04 +02:00

Revert "nvmem: add new config option" This reverts commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f. Config option "no_of_node" is no longer needed since adding a more explicit and targeted option "add_legacy_fixed_of_cells". That "no_of_node" config option was needed *earlier* to help mtd's case. DT nodes of MTD partitions (that are also NVMEM devices) may contain subnodes. Those SHOULD NOT be treated as NVMEM fixed cells. To prevent NVMEM core code from parsing subnodes a "no_of_node" option was added (and set to true in mtd) to make for_each_child_of_node() in NVMEM a no-op. That was a bit hacky because it was messing with "of_node" pointer to achieve some side-effect. With the introduction of "add_legacy_fixed_of_cells" config option things got more explicit. MTD subsystem simply tells NVMEM when to look for fixed cells and there is no need to hack "of_node" pointer anymore. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231023102759.31529-1-zajec5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-10-23 12:27:59 +02:00

nvmem: add new config option We want to add nvmem support for MTD. TI DaVinci is the first platform that will be using it, but only in non-DT mode. In order not to introduce any new interface to supporting of which we would have to commit - add a new config option that tells nvmem not to use the DT node of the parent device. This way we won't be creating nvmem devices corresponding with MTD partitions defined in device tree. By default MTD will set this new field to true. Once a set of bindings for MTD nvmem cells is agreed upon, we'll be able to remove this option. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-11-30 11:53:25 +00:00

nvmem: core: Allow specifying device name verbatim Add code to allow avoid having nvmem core append a numeric suffix to the end of the name by passing config->id of -1. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:56 +00:00

nvmem: core: add support to auto devid For nvmem providers which have multiple instances, it is required to suffix the provider name with proper id, so that they do not confict for the same name. Currently the core does not handle this case properly eventhough core already has logic to generate the id. This patch add new devid type NVMEM_DEVID_AUTO for providers to be able to allow core to assign id and append it to provier name. Reported-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:58 +01:00

nvmem: core: add error handling for dev_set_name The type of return value of dev_set_name is int, which may return wrong result, so we add error handling for it to reclaim memory of nvmem resource, and return early when an error occurs. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916122100.170016-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:20:50 +01:00

nvmem: core: add support to auto devid For nvmem providers which have multiple instances, it is required to suffix the provider name with proper id, so that they do not confict for the same name. Currently the core does not handle this case properly eventhough core already has logic to generate the id. This patch add new devid type NVMEM_DEVID_AUTO for providers to be able to allow core to assign id and append it to provier name. Reported-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:58 +01:00

nvmem: core: add error handling for dev_set_name The type of return value of dev_set_name is int, which may return wrong result, so we add error handling for it to reclaim memory of nvmem resource, and return early when an error occurs. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916122100.170016-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:20:50 +01:00

nvmem: core: add support to auto devid For nvmem providers which have multiple instances, it is required to suffix the provider name with proper id, so that they do not confict for the same name. Currently the core does not handle this case properly eventhough core already has logic to generate the id. This patch add new devid type NVMEM_DEVID_AUTO for providers to be able to allow core to assign id and append it to provier name. Reported-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:58 +01:00

nvmem: core: add error handling for dev_set_name The type of return value of dev_set_name is int, which may return wrong result, so we add error handling for it to reclaim memory of nvmem resource, and return early when an error occurs. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916122100.170016-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:20:50 +01:00

nvmem: core: Allow specifying device name verbatim Add code to allow avoid having nvmem core append a numeric suffix to the end of the name by passing config->id of -1. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:56 +00:00

nvmem: core: add support to auto devid For nvmem providers which have multiple instances, it is required to suffix the provider name with proper id, so that they do not confict for the same name. Currently the core does not handle this case properly eventhough core already has logic to generate the id. This patch add new devid type NVMEM_DEVID_AUTO for providers to be able to allow core to assign id and append it to provier name. Reported-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:58 +01:00

nvmem: core: Allow specifying device name verbatim Add code to allow avoid having nvmem core append a numeric suffix to the end of the name by passing config->id of -1. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:56 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". Fixes: 5544e90c8126 ("nvmem: core: add error handling for dev_set_name") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [Srini: Fixed subject line and error code handing with wp_gpio while applying.] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:10 +00:00

nvmem: core: add error handling for dev_set_name The type of return value of dev_set_name is int, which may return wrong result, so we add error handling for it to reclaim memory of nvmem resource, and return early when an error occurs. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916122100.170016-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:20:50 +01:00

nvmem: core: Set the provider read-only when no write callback is given If no write callback is given the device should be marked as read-only. While at it also move from a bit or to a logical or as that is a logical expression. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:00 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: remove nvmem_sysfs_get_groups() Now that we are using is_bin_visible callback, we do not need nvmem_sysfs_get_groups() anymore so move all the relevant data-structures and code to core.c Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200325131951.31887-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-25 13:19:51 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Fix memleak in nvmem_register() dev_set_name will alloc memory for nvmem->dev.kobj.name in nvmem_register, when nvmem_validate_keepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmem_validate_keepouts() after device_register() and let the device core deal with cleaning name in error cases. Fixes: de0534df9347 ("nvmem: core: fix error handling while validating keepout regions") Cc: stable@vger.kernel.org Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916120402.38753-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:04:02 +01:00

nvmem: core: fix registration vs use race The i.MX6 CPU frequency driver sometimes fails to register at boot time due to nvmem_cell_read_u32() sporadically returning -ENOENT. This happens because there is a window where __nvmem_device_get() in of_nvmem_cell_get() is able to return the nvmem device, but as cells have been setup, nvmem_find_cell_entry_by_node() returns NULL. The occurs because the nvmem core registration code violates one of the fundamental principles of kernel programming: do not publish data structures before their setup is complete. Fix this by making nvmem core code conform with this principle. Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers") Cc: stable@vger.kernel.org Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:11 +00:00

nvmem: core: Fix memleak in nvmem_register() dev_set_name will alloc memory for nvmem->dev.kobj.name in nvmem_register, when nvmem_validate_keepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmem_validate_keepouts() after device_register() and let the device core deal with cleaning name in error cases. Fixes: de0534df9347 ("nvmem: core: fix error handling while validating keepout regions") Cc: stable@vger.kernel.org Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916120402.38753-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-09-16 13:04:02 +01:00

nvmem: Add backwards compatibility support for older EEPROM drivers. Older drivers made an 'eeprom' file available in the /sys device directory. Have the NVMEM core provide this to retain backwards compatibility. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-02-26 20:59:19 +01:00

nvmem: core: add NVMEM_SYSFS Kconfig Many nvmem providers are not very keen on having default sysfs nvmem entry, as most of the usecases for them are inside kernel itself. And in some cases read/writes to some areas in nvmem are restricted and trapped at secure monitor level, so accessing them from userspace would result in board reboots. This patch adds new NVMEM_SYSFS Kconfig to make binary sysfs entry an optional one. This provision will give more flexibility to users. This patch also moves existing sysfs code to a new file so that its not compiled in when its not really required. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Gaurav Kohli <gkohli@codeaurora.org> Tested-by: Gaurav Kohli <gkohli@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-16 10:59:24 +01:00

nvmem: Add backwards compatibility support for older EEPROM drivers. Older drivers made an 'eeprom' file available in the /sys device directory. Have the NVMEM core provide this to retain backwards compatibility. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-02-26 20:59:19 +01:00

nvmem: core: fix registration vs use race The i.MX6 CPU frequency driver sometimes fails to register at boot time due to nvmem_cell_read_u32() sporadically returning -ENOENT. This happens because there is a window where __nvmem_device_get() in of_nvmem_cell_get() is able to return the nvmem device, but as cells have been setup, nvmem_find_cell_entry_by_node() returns NULL. The occurs because the nvmem core registration code violates one of the fundamental principles of kernel programming: do not publish data structures before their setup is complete. Fix this by making nvmem core code conform with this principle. Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers") Cc: stable@vger.kernel.org Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:11 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: check the return value of nvmem_add_cells() This function can fail so check its return value in nvmem_register() and act accordingly. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:07 -07:00

nvmem: core: fix cell removal on error nvmem_add_cells() could return an error after some cells are already added to the provider. In this case, the added cells are not removed. Remove any registered cells if nvmem_add_cells() fails. Fixes: fa72d847d68d7 ("nvmem: check the return value of nvmem_add_cells()") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:13 +00:00

nvmem: check the return value of nvmem_add_cells() This function can fail so check its return value in nvmem_register() and act accordingly. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:07 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: add explicit config option to read old syntax fixed OF cells Binding for fixed NVMEM cells defined directly as NVMEM device subnodes has been deprecated. It has been replaced by the "fixed-layout" NVMEM layout binding. New syntax is meant to be clearer and should help avoiding imprecise bindings. NVMEM subsystem already supports the new binding. It should be a good idea to limit support for old syntax to existing drivers that actually support & use it (we can't break backward compatibility!). That way we additionally encourage new bindings & drivers to ignore deprecated binding. It wasn't clear (to me) if rtc and w1 code actually uses old syntax fixed cells. I enabled them to don't risk any breakage. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> [for meson-{efuse,mx-efuse}.c] Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [for mtk-efuse.c, nvmem/core.c, nvmem-provider.h] Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [MT8192, MT8195 Chromebooks] Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [for microchip-otpc.c] Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> [SAMA7G5-EK] Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-10-20 11:55:41 +01:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: add support for fixed cells *layout* This adds support for the "fixed-layout" NVMEM layout binding. It allows defining NVMEM cells in a layout DT node named "nvmem-layout". While NVMEM subsystem supports layout drivers it has been discussed that "fixed-layout" may actually be supperted internally. It's because: 1. It's a very basic layout 2. It allows sharing code with legacy syntax parsing 3. It's safer for soc_device_match() due to -EPROBE_DEFER 4. This will make the syntax transition easier Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Message-ID: <20230611140330.154222-26-srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-06-11 15:03:29 +01:00

nvmem: core: Create all cells before adding the nvmem device Let's pack all the cells creation in one place, so they are all created before we add the nvmem device. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230823132744.350618-20-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-08-23 14:27:41 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: don't check the return value of notifier chain call blocking_notifier_call_chain() returns the value returned by the last registered callback. A positive return value doesn't indicate an error and an nvmem device should correctly register irrespective of any notifier callback failures. Drop the retval check. Fixes: bee1138bea15 ("nvmem: add a notifier chain") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-02-15 11:42:59 +01:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: fix leaks on registration errors Make sure to deregister and release the nvmem device and underlying memory on registration errors. Note that the private data must be freed using put_device() once the struct device has been initialised. Also note that there's a related reference leak in the deregistration function as reported by Mika Westerberg which is being fixed separately. Fixes: b6c217ab9be6 ("nvmem: Add backwards compatibility support for older EEPROM drivers.") Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers") Cc: stable <stable@vger.kernel.org> # 4.3 Cc: Andrew Lunn <andrew@lunn.ch> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-06-09 10:59:07 +01:00

nvmem: core: Expose cells through sysfs 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 <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:34 +00:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: check the return value of nvmem_add_cells() This function can fail so check its return value in nvmem_register() and act accordingly. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:07 -07:00

nvmem: core: add NVMEM_SYSFS Kconfig Many nvmem providers are not very keen on having default sysfs nvmem entry, as most of the usecases for them are inside kernel itself. And in some cases read/writes to some areas in nvmem are restricted and trapped at secure monitor level, so accessing them from userspace would result in board reboots. This patch adds new NVMEM_SYSFS Kconfig to make binary sysfs entry an optional one. This provision will give more flexibility to users. This patch also moves existing sysfs code to a new file so that its not compiled in when its not really required. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Gaurav Kohli <gkohli@codeaurora.org> Tested-by: Gaurav Kohli <gkohli@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-16 10:59:24 +01:00

nvmem: core: fix leaks on registration errors Make sure to deregister and release the nvmem device and underlying memory on registration errors. Note that the private data must be freed using put_device() once the struct device has been initialised. Also note that there's a related reference leak in the deregistration function as reported by Mika Westerberg which is being fixed separately. Fixes: b6c217ab9be6 ("nvmem: Add backwards compatibility support for older EEPROM drivers.") Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers") Cc: stable <stable@vger.kernel.org> # 4.3 Cc: Andrew Lunn <andrew@lunn.ch> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-06-09 10:59:07 +01:00

nvmem: Add backwards compatibility support for older EEPROM drivers. Older drivers made an 'eeprom' file available in the /sys device directory. Have the NVMEM core provide this to retain backwards compatibility. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-02-26 20:59:19 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: add a notifier chain Add a blocking notifier chain with four events (add and remove for both devices and cells) so that users can get notified about the addition of nvmem resources they're waiting for. We'll use this instead of the at24 setup callback in the mityomapl138 board file. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:19 -07:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: use device_register and device_unregister use device_register/unregister instead of spliting them with no use. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200324171600.15606-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-24 17:15:58 +00:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: change the signature of nvmem_unregister() We switched the nvmem framework to using kref instead of manually checking the current number of users in nvmem_unregister() so this function can no longer fail. We also converted all remaining users that still checked the return value of nvmem_unregister() to using devm_nvmem_register(). Make the routine return void. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:13 -07:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Check input parameter for NULL in nvmem_unregister() nvmem_unregister() frees resources and standard pattern is to allow caller to not care if it's NULL or not. This will reduce burden on the callers to perform this check. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:17 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Use devm_add_action_or_reset() Slightly simplify the devm_nvmem_register() by using the devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:16 +00:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: Use devm_add_action_or_reset() Slightly simplify the devm_nvmem_register() by using the devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:16 +00:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: Grammar fixes for help text It's "an unsigned" but "a U". Similarly, "an entry" but "a binary entry". While at it, also drop superfluous articles for negative and zero. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:56 +01:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: describe add missing dev function parameter Document dev parameter which not described in devm_nvmem_unregister and devm_nvmem_register functions. Fix below warnings when kernel is compiled with W=1 drivers/nvmem/core.c:579: warning: Function parameter or member 'dev' not described in 'devm_nvmem_register' nvmem/core.c:615: warning: Function parameter or member 'dev' not described in 'devm_nvmem_unregister' Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:07:02 +01:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: Use devm_add_action_or_reset() Slightly simplify the devm_nvmem_register() by using the devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:16 +00:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: Use devm_add_action_or_reset() Slightly simplify the devm_nvmem_register() by using the devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:16 +00:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: Use devm_add_action_or_reset() Slightly simplify the devm_nvmem_register() by using the devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220220151527.17216-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2022-02-20 15:15:16 +00:00

nvmem: Introduce devm_nvmem_(un)register() Introduce devm_nvmem_register()/devm_nvmem_unregister() to make .remove() unnecessary in trivial drivers. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: cphealy@gmail.com Cc: linux-kernel@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-03-09 14:46:57 +00:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: remove the global cell list Nvmem subsystem keeps a global list of cells that, for non-DT systems, can only be referenced by cell name, which makes it impossible to have more than one nvmem device with cells named the same. This patch makes every nvmem device the owner of the list of its cells. This effectively removes the support for non-DT systems, but it will be reintroduced following a different approach in subsequent patches. This isn't a problem as support for board files in nvmem is currently broken anyway: any user that would try to get an nvmem cell from the global cell list would remove the cell after the calling nvmem_cell_put(). This can cause anything from a subsequent user not being able to get the cell to double free errors if more users hold reference to the same cell at the same time. Fortunately there are no such users which allows us to rework this part. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:14 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: remove the name field from struct nvmem_device This field is never set and is only used in a single error message. Remove the field and use nvmem_dev_name() instead. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:04 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Fix device reference leak __nvmem_device_get() make use of bus_find_device() to get the relevant device and this function increase the reference count of the device found, however this is not accounted for anywhere. Fix __nvmem_device_get() and __nvmem_device_put() to properly release this reference count. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:05 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Fix device reference leak __nvmem_device_get() make use of bus_find_device() to get the relevant device and this function increase the reference count of the device found, however this is not accounted for anywhere. Fix __nvmem_device_get() and __nvmem_device_put() to properly release this reference count. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:05 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: use kref Use kref for reference counting. Use an approach similar to the one seen in the common clock subsystem: don't actually destroy the nvmem device until the last user puts it. This way we can get rid of the users check from nvmem_unregister(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:08 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: remove unneeded IS_ENABLED(CONFIG_NVMEM) conditional As you see in drivers/nvmem/Makefile, this C file is compiled only when CONFIG_NVMEM is y or m. So, IS_ENABLED(CONFIG_NVMEM) is always evaluated to 1 in this file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-09-11 11:00:14 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: fix missing of_node_put() in of_nvmem_device_get() of_parse_phandle() returns device_node with incremented ref count which needs to be decremented by of_node_put() when device_node is not used. Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:37 +01:00

nvmem: core: Properly handle connection ID in of_nvmem_device_get() of_nvmem_device_get() would crash if NULL was passed as a connection ID. Rework this to use the usual sementic of assuming the first connection when no connection ID is given. Furthermore of_nvmem_device_get() would return -EINVAL when it failed to resolve the connection, making it impossible to properly implement an optional connection. Return -ENOENT instead to let the caller know that the connection doesn't exists. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:03 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Properly handle connection ID in of_nvmem_device_get() of_nvmem_device_get() would crash if NULL was passed as a connection ID. Rework this to use the usual sementic of assuming the first connection when no connection ID is given. Furthermore of_nvmem_device_get() would return -EINVAL when it failed to resolve the connection, making it impossible to properly implement an optional connection. Return -ENOENT instead to let the caller know that the connection doesn't exists. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:03 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Properly handle connection ID in of_nvmem_device_get() of_nvmem_device_get() would crash if NULL was passed as a connection ID. Rework this to use the usual sementic of assuming the first connection when no connection ID is given. Furthermore of_nvmem_device_get() would return -EINVAL when it failed to resolve the connection, making it impossible to properly implement an optional connection. Return -ENOENT instead to let the caller know that the connection doesn't exists. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:03 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: fix missing of_node_put() in of_nvmem_device_get() of_parse_phandle() returns device_node with incremented ref count which needs to be decremented by of_node_put() when device_node is not used. Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200917134437.16637-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-09-17 14:44:37 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: Correct some typos in comments Fixed some confusing typos that were currently identified with codespell, the details are as follows: -in the code comments: drivers/nvmem/brcm_nvram.c:25: underlaying ==> underlying drivers/nvmem/core.c:1250: alredy ==> already drivers/nvmem/core.c:1268: alredy ==> already drivers/nvmem/lpc18xx_otp.c:24: reseverd ==> reserved drivers/nvmem/microchip-otpc.c:159: devide ==> divide Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241030140315.40562-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-10-30 14:03:11 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: Correct some typos in comments Fixed some confusing typos that were currently identified with codespell, the details are as follows: -in the code comments: drivers/nvmem/brcm_nvram.c:25: underlaying ==> underlying drivers/nvmem/core.c:1250: alredy ==> already drivers/nvmem/core.c:1268: alredy ==> already drivers/nvmem/lpc18xx_otp.c:24: reseverd ==> reserved drivers/nvmem/microchip-otpc.c:159: devide ==> divide Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241030140315.40562-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-10-30 14:03:11 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: Fix return type of devm_nvmem_device_get() in kerneldoc devm_nvmem_device_get() returns an nvmem device, not an nvmem cell. Fixes: e2a5402ec7c6d044 ("nvmem: Add nvmem_device based consumer apis.") Cc: stable <stable@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240902142510.71096-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-09-02 15:25:09 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: Fix return type of devm_nvmem_device_get() in kerneldoc devm_nvmem_device_get() returns an nvmem device, not an nvmem cell. Fixes: e2a5402ec7c6d044 ("nvmem: Add nvmem_device based consumer apis.") Cc: stable <stable@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20240902142510.71096-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-09-02 15:25:09 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: fix nvmem_cell_get_from_lookup() We check if the pointer returned by __nvmem_device_get() is not NULL while we should actually check if it is not IS_ERR(nvmem). Fix it. While we're at it: fix the next error path where we should assign an error value to cell before returning. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-03 09:31:11 +02:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: fix nvmem_cell_get_from_lookup() We check if the pointer returned by __nvmem_device_get() is not NULL while we should actually check if it is not IS_ERR(nvmem). Fix it. While we're at it: fix the next error path where we should assign an error value to cell before returning. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-03 09:31:11 +02:00

nvmem: core: Avoid useless iterations in nvmem_cell_get_from_lookup() Once the correct cell has been found there is no need to continue iterating, just stop there. While at it replace the goto used to leave the loop with simple break statements. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:06 +00:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: fix nvmem_cell_get_from_lookup() We check if the pointer returned by __nvmem_device_get() is not NULL while we should actually check if it is not IS_ERR(nvmem). Fix it. While we're at it: fix the next error path where we should assign an error value to cell before returning. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-03 09:31:11 +02:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: core: Avoid useless iterations in nvmem_cell_get_from_lookup() Once the correct cell has been found there is no need to continue iterating, just stop there. While at it replace the goto used to leave the loop with simple break statements. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:06 +00:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: remove unneeded IS_ENABLED(CONFIG_NVMEM) conditional As you see in drivers/nvmem/Makefile, this C file is compiled only when CONFIG_NVMEM is y or m. So, IS_ENABLED(CONFIG_NVMEM) is always evaluated to 1 in this file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-09-11 11:00:14 +02:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: hide unused nvmem_find_cell_by_index function nvmem_find_cell_by_index() is only called from inside an #ifdef, so we get a build warning without CONFIG_OF: drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not used [-Werror=unused-function] Move it into the same #ifdef as the caller to avoid the warning. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-02 23:11:12 +02:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: hide unused nvmem_find_cell_by_index function nvmem_find_cell_by_index() is only called from inside an #ifdef, so we get a build warning without CONFIG_OF: drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not used [-Werror=unused-function] Move it into the same #ifdef as the caller to avoid the warning. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-02 23:11:12 +02:00

nvmem: core: Fix cell lookup when no cell is found If the cell list is not empty and nvmem_find_cell_by_node/name() is called for a cell that is not present in the list they will return an invalid pointer instead of NULL. This happen because list_for_each_entry() stop once it reach the list head again, but as the list head is not contained in a struct nvmem_cell the iteration variable then contains an invalid value. This is easily solved by using a variable to iterate over the list and one to return the cell found. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:02 +00:00

nvmem: hide unused nvmem_find_cell_by_index function nvmem_find_cell_by_index() is only called from inside an #ifdef, so we get a build warning without CONFIG_OF: drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not used [-Werror=unused-function] Move it into the same #ifdef as the caller to avoid the warning. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-02 23:11:12 +02:00

nvmem: core: Fix cell lookup when no cell is found If the cell list is not empty and nvmem_find_cell_by_node/name() is called for a cell that is not present in the list they will return an invalid pointer instead of NULL. This happen because list_for_each_entry() stop once it reach the list head again, but as the list head is not contained in a struct nvmem_cell the iteration variable then contains an invalid value. This is easily solved by using a variable to iterate over the list and one to return the cell found. Signed-off-by: Alban Bedel <albeu@free.fr> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-01-28 15:55:02 +00:00

nvmem: hide unused nvmem_find_cell_by_index function nvmem_find_cell_by_index() is only called from inside an #ifdef, so we get a build warning without CONFIG_OF: drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not used [-Werror=unused-function] Move it into the same #ifdef as the caller to avoid the warning. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-10-02 23:11:12 +02:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: Allow getting nvmem cell with a NULL cell id The nvmem cell with a NULL cell name/id should be the one with no accompanying 'nvmem-cell-names' property, and thus will be the cell at index 0 in the device tree. So, we default to index 0 and update the cell index only when nvmem cell name id exists. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:40 +00:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Allow getting nvmem cell with a NULL cell id The nvmem cell with a NULL cell name/id should be the one with no accompanying 'nvmem-cell-names' property, and thus will be the cell at index 0 in the device tree. So, we default to index 0 and update the cell index only when nvmem cell name id exists. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:40 +00:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: return -ENOENT if nvmem cell is not found Prior to commit 5d8e6e6c10a3 ("nvmem: core: add an index parameter to the cell") of_nvmem_cell_get() would return -ENOENT if the cell wasn't found. Particularly, if of_property_match_string() returned -EINVAL, that return code was passed as the index to of_parse_phandle(), which then detected it as invalid and returned NULL. That led to an return code of -ENOENT. With the new code, the negative index will lead to an -EINVAL of of_parse_phandle_with_optional_args() which pass straight to the caller and break those who expect an -ENOENT. Fix it by always returning -ENOENT. Fixes: 5d8e6e6c10a3 ("nvmem: core: add an index parameter to the cell") Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/2143916.GUh0CODmnK@steina-w/ Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230310094845.139400-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-03-10 09:48:45 +00:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix device node refcounting In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:12 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix device node refcounting In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:12 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: introduce NVMEM layouts NVMEM layouts are used to generate NVMEM cells during runtime. Think of an EEPROM with a well-defined conent. For now, the content can be described by a device tree or a board file. But this only works if the offsets and lengths are static and don't change. One could also argue that putting the layout of the EEPROM in the device tree is the wrong place. Instead, the device tree should just have a specific compatible string. Right now there are two use cases: (1) The NVMEM cell needs special processing. E.g. if it only specifies a base MAC address offset and you need to add an offset, or it needs to parse a MAC from ASCII format or some proprietary format. (Post processing of cells is added in a later commit). (2) u-boot environment parsing. The cells don't have a particular offset but it needs parsing the content to determine the offsets and length. Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:21 +01:00

nvmem: core: add nvmem_device_find nvmem_device_find provides a way to search for nvmem devices with the help of a match function simlair to bus_find_device. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: David S. Miller <davem@davemloft.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-serial@vger.kernel.org

2019-10-03 11:52:29 +02:00

nvmem: add missing of_node_put() in of_nvmem_cell_get() of_get_next_parent() increments the refcount of the returned node. It should be put when done. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-09-11 11:00:12 +02:00

nvmem: core: fix device node refcounting In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:12 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix device node refcounting In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:12 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: fix device node refcounting In of_nvmem_cell_get(), of_get_next_parent() is used on cell_np. This will decrement the refcount on cell_np, but cell_np is still used later in the code. Use of_get_parent() instead and of_node_put() in the appropriate places. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Cc: stable@vger.kernel.org Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230127104015.23839-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-01-27 10:40:12 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: resolve cells from DT at registration time Currently we're creating a new cell structure everytime a DT user calls nvmem_cell_get(). Change this behavior by resolving the cells during nvmem provider registration and adding all cells to the provider's list. Make of_nvmem_cell_get() just parse the phandle and look the cell up in the relevant provider's list. Don't drop the cell in nvmem_cell_put(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:16 -07:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Don't let a NULL cell_id for nvmem_cell_get() crash us In commit ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips") you can see a call like: devm_nvmem_cell_get(dev, NULL); Note that the cell ID passed to the function is NULL. This is because the qcom-qusb2 driver is expected to work only on systems where the PHY node is hooked up via device-tree and is nameless. This works OK for the most part. The first thing nvmem_cell_get() does is to call of_nvmem_cell_get() and there it's documented that a NULL name is fine. The problem happens when the call to of_nvmem_cell_get() returns -EINVAL. In such a case we'll fall back to nvmem_cell_get_from_list() and eventually might (if nvmem_cells isn't an empty list) crash with something that looks like: strcmp nvmem_find_cell __nvmem_device_get nvmem_cell_get_from_list nvmem_cell_get devm_nvmem_cell_get qusb2_phy_probe There are several different ways we could fix this problem: One could argue that perhaps the qcom-qusb2 driver should be changed to use of_nvmem_cell_get() which is allowed to have a NULL name. In that case, we'd need to add a patche to introduce devm_of_nvmem_cell_get() since the qcom-qusb2 driver is using devm managed resources. One could also argue that perhaps we could just add a name to qcom-qusb2. That would be OK but I believe it effectively changes the device tree bindings, so maybe it's a no-go. In this patch I have chosen to fix the problem by simply not crashing when a NULL cell_id is passed to nvmem_cell_get(). NOTE: that for the qcom-qusb2 driver the "nvmem-cells" property is defined to be optional and thus it's expected to be a common case that we would hit this crash and this is more than just a theoretical fix. Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-06-18 18:30:43 +01:00

nvmem: make the naming of arguments in nvmem_cell_get() consistent The argument representing the cell name in the nvmem_cell_get() family of functions is not consistend between function prototypes and definitions. Name it 'id' in all those routines. This is in line with other frameworks and can represent both the DT cell name from the nvmem-cell-names property as well as the con_id field from cell lookup entries. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:21 -07:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix read buffer in place When the bit_offset in the cell is zero, the pointer to the msb will not be properly initialized (ie, will still be pointing to the first byte in the buffer). This being the case, if there are bits to clear in the msb, those will be left untouched while the mask will incorrectly clear bit positions on the first byte. This commit also makes sure that any byte unused in the cell is cleared. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:58 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix read buffer in place When the bit_offset in the cell is zero, the pointer to the msb will not be properly initialized (ie, will still be pointing to the first byte in the buffer). This being the case, if there are bits to clear in the msb, those will be left untouched while the mask will incorrectly clear bit positions on the first byte. This commit also makes sure that any byte unused in the cell is cleared. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:58 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: fix read buffer in place When the bit_offset in the cell is zero, the pointer to the msb will not be properly initialized (ie, will still be pointing to the first byte in the buffer). This being the case, if there are bits to clear in the msb, those will be left untouched while the mask will incorrectly clear bit positions on the first byte. This commit also makes sure that any byte unused in the cell is cleared. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:58 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: Douglas Anderson <dianders@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 13:45:11 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Handle shift bits in-place if cell->nbits is non-zero It's pointless to test (cell->bit_offset || cell->bit_offset). nvmem_shift_read_buffer_in_place() should be called when (cell->bit_offset || cell->nbits). Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-09-30 13:35:15 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add per-cell post processing Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:24 +01:00

nvmem: core: provide own priv pointer in post process callback It doesn't make any more sense to have a opaque pointer set up by the nvmem device. Usually, the layout isn't associated with a particular nvmem device. Instead, let the caller who set the post process callback provide the priv pointer. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-21-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:28 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: core: add per-cell post processing Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:24 +01:00

nvmem: core: Allow ignoring length when reading a cell nvmem_cell_read() API fills in the argument 'len' with the number of bytes read from the cell. Many users don't care about this length value. So allow users to pass a NULL pointer to this len field. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:38 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Allow ignoring length when reading a cell nvmem_cell_read() API fills in the argument 'len' with the number of bytes read from the cell. Many users don't care about this length value. So allow users to pass a NULL pointer to this len field. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:38 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: fix nvmem_cell_read() return type doc nvmem_cell_read() returns void *, not char *. This is a cleanup that got left out of commit a6c50912508d ("nvmem: Declare nvmem_cell_read() consistently"). Signed-off-by: Brian Norris <briannorris@chromium.org> Fixes: a6c50912508d ("nvmem: Declare nvmem_cell_read() consistently") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-04 16:18:11 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: support specifying both: cell raw data & post read lengths Callback .read_post_process() is designed to modify raw cell content before providing it to the consumer. So far we were dealing with modifications that didn't affect cell size (length). In some cases however cell content needs to be reformatted and resized. It's required e.g. to provide properly formatted MAC address in case it's stored in a non-binary format (e.g. using ASCII). There were few discussions how to optimally handle that. Following possible solutions were considered: 1. Allow .read_post_process() to realloc (resize) content buffer 2. Allow .read_post_process() to adjust (decrease) just buffer length 3. Register NVMEM cells using post-read sizes The preferred solution was the last one. The problem is that simply adjusting "bytes" in NVMEM providers would result in core code NOT passing whole raw data to .read_post_process() callbacks. It means callback functions couldn't do their job without somehow manually reading original cell content on their own. This patch deals with that by registering NVMEM cells with both lengths: raw content one and post read one. It allows: 1. Core code to read whole raw cell content 2. Callbacks to return content they want Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:42 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: remove inline in drivers/nvmem/core.c These two functions are defined in .c file, but called just once (at least for now). So, the compiler will fold them into their callers even without the "inline" markers. However, this kind of optimization should not be done by hand. It is compiler's judge after all. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-09-11 11:00:13 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: properly handle returned value nvmem_reg_read Function nvmem_reg_read can return a non zero value indicating an error. This returned value must be read and error propagated to nvmem_cell_prepare_write_buffer. Silence the following gcc warning (W=1): drivers/nvmem/core.c:1093:9: warning: variable 'rc' set but not used [-Wunused-but-set-variable] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:07:03 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: properly handle returned value nvmem_reg_read Function nvmem_reg_read can return a non zero value indicating an error. This returned value must be read and error propagated to nvmem_cell_prepare_write_buffer. Silence the following gcc warning (W=1): drivers/nvmem/core.c:1093:9: warning: variable 'rc' set but not used [-Wunused-but-set-variable] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:07:03 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: properly handle returned value nvmem_reg_read Function nvmem_reg_read can return a non zero value indicating an error. This returned value must be read and error propagated to nvmem_cell_prepare_write_buffer. Silence the following gcc warning (W=1): drivers/nvmem/core.c:1093:9: warning: variable 'rc' set but not used [-Wunused-but-set-variable] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-05-11 12:07:03 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add per-cell post processing Instead of relying on the name the consumer is using for the cell, like it is done for the nvmem .cell_post_process configuration parameter, provide a per-cell post processing hook. This can then be populated by the NVMEM provider (or the NVMEM layout) when adding the cell. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-04-04 18:21:24 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: improve range check for nvmem_cell_write() When __nvmem_cell_entry_write() is called for an nvmem cell that does not need bit shifting, it requires that the len parameter exactly matches the nvmem cell size. However, when the nvmem cell has a nonzero bit_offset, it was skipping this check. Accepting values of len larger than the cell size results in nvmem_cell_prepare_write_buffer() trying to write past the end of a heap buffer that it allocates. Add a check to avoid that problem and instead return -EINVAL when len doesn't match the number of bits expected by the nvmem cell when bit_offset is nonzero. This check uses cell->nbits in order to allow providing the smaller size to cells that are shifted into another byte by bit_offset. For example, a cell with nbits=8 and nonzero bit_offset would have bytes=2 but should accept a 1-byte write here, although no current callers depend on this. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: stable@vger.kernel.org Signed-off-by: Jennifer Berringer <jberring@redhat.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20241230141901.263976-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2024-12-30 14:19:01 +00:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: Fix memory leak in nvmem_cell_write A tmp buffer is allocated if cell->bit_offset || cell->nbits. So the tmp buffer needs to be freed at the same condition to avoid leak. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-09-30 13:36:10 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add a simple NVMEM framework for consumers This patch adds just consumers part of the framework just to enable easy review. Up until now, nvmem drivers were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of the framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:34 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: add nvmem_cell_read_u16 Add nvmem_cell_read_u16() helper to ease read of an u16 value on consumer side. This is inspired by nvmem_cell_read_u32() function. This helper is useful on stm32 that has 16 bits data cells stored in non volatile memory. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:57 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: add nvmem_cell_read_u16 Add nvmem_cell_read_u16() helper to ease read of an u16 value on consumer side. This is inspired by nvmem_cell_read_u32() function. This helper is useful on stm32 that has 16 bits data cells stored in non volatile memory. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:57 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: add nvmem_cell_read_u16 Add nvmem_cell_read_u16() helper to ease read of an u16 value on consumer side. This is inspired by nvmem_cell_read_u32() function. This helper is useful on stm32 that has 16 bits data cells stored in non volatile memory. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:57 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: Add nvmem_cell_read_u8() Complement the u16, u32 and u64 helpers with a u8 variant to ease accessing byte-sized values. This helper will be useful for Realtek Digital Home Center platforms, which store some byte and sub-byte sized values in non-volatile memory. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:57 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: Grammar fixes for help text It's "an unsigned" but "a U". Similarly, "an entry" but "a binary entry". While at it, also drop superfluous articles for negative and zero. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:56 +01:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: add nvmem_cell_read_u16 Add nvmem_cell_read_u16() helper to ease read of an u16 value on consumer side. This is inspired by nvmem_cell_read_u32() function. This helper is useful on stm32 that has 16 bits data cells stored in non volatile memory. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2019-04-13 11:32:57 +01:00

nvmem: core: Add nvmem_cell_read_u32 This function does a quick and easy read of an u32 value without any kind of resource management code on the consumer side. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-07-26 11:34:46 +02:00

nvmem: core: Grammar fixes for help text It's "an unsigned" but "a U". Similarly, "an entry" but "a binary entry". While at it, also drop superfluous articles for negative and zero. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:56 +01:00

nvmem: core: Add nvmem_cell_read_u32 This function does a quick and easy read of an u32 value without any kind of resource management code on the consumer side. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-07-26 11:34:46 +02:00

nvmem: core: add nvmem_cell_read_common Now there are nvmem_cell_read_u16 and nvmem_cell_read_u32. They are very similar, let's strip out a common part. And use nvmem_cell_read_common to simplify their implementation. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:45 +00:00

nvmem: core: Add nvmem_cell_read_u32 This function does a quick and easy read of an u32 value without any kind of resource management code on the consumer side. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-07-26 11:34:46 +02:00

nvmem: core: add nvmem_cell_read_u64 Add nvmem_cell_read_u64() helper to ease read of an u64 value on consumer side. This helper is useful on some sunxi platform that has 64 bits data cells stored in no volatile memory. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:46 +00:00

nvmem: core: Grammar fixes for help text It's "an unsigned" but "a U". Similarly, "an entry" but "a binary entry". While at it, also drop superfluous articles for negative and zero. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200722100705.7772-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-07-22 11:06:56 +01:00

nvmem: core: add nvmem_cell_read_u64 Add nvmem_cell_read_u64() helper to ease read of an u64 value on consumer side. This helper is useful on some sunxi platform that has 64 bits data cells stored in no volatile memory. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200310132257.23358-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2020-03-10 13:22:46 +00:00

nvmem: core: constify nvmem_cell_read_variable_common() return value The caller doesn't modify the memory pointed to by the pointer so it can be const. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611083348.20170-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 09:33:47 +01:00

nvmem: core: Add functions to make number reading easy 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@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210330111241.19401-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:37 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: core: Add functions to make number reading easy 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@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210330111241.19401-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:37 +01:00

nvmem: core: constify nvmem_cell_read_variable_common() return value The caller doesn't modify the memory pointed to by the pointer so it can be const. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611083348.20170-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 09:33:47 +01:00

nvmem: core: Add functions to make number reading easy 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@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210330111241.19401-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:37 +01:00

nvmem: core: constify nvmem_cell_read_variable_common() return value The caller doesn't modify the memory pointed to by the pointer so it can be const. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611083348.20170-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-06-11 09:33:47 +01:00

nvmem: core: Add functions to make number reading easy 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@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210330111241.19401-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:37 +01:00

nvmem: core: Fix unintentional sign extension issue The shifting of the u8 integer buf[3] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of buf[3] is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting buf[i] to a u64 before the shift. Fixes: a28e824fb827 ("nvmem: core: Add functions to make number reading easy") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Addresses-Coverity: ("Unintended sign extension") Link: https://lore.kernel.org/r/20210330111241.19401-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:38 +01:00

nvmem: core: Add functions to make number reading easy 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@chromium.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210330111241.19401-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-03-30 12:12:37 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: add an index parameter to the cell Sometimes a cell can represend multiple values. For example, a base ethernet address stored in the NVMEM can be expanded into multiple discreet ones by adding an offset. For this use case, introduce an index parameter which is then used to distiguish between values. This parameter will then be passed to the post process hook which can then use it to create different values during reading. At the moment, there is only support for the device tree path. You can add the index to the phandle, e.g. &net { nvmem-cells = <&base_mac_address 2>; nvmem-cell-names = "mac-address"; }; &nvmem_provider { base_mac_address: base-mac-address@0 { #nvmem-cell-cells = <1>; reg = <0 6>; }; }; Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230206134356.839737-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-02-06 13:43:46 +00:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: Correct a bunch of function documentations Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2017-01-22 23:02:39 +00:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: fix commenting style Remove a redundant '*/' as pointed out by checkpatch. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:23 -07:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: rework nvmem cell instance creation In the existing design, we do not create a instance per nvmem cell consumer but we directly refer cell from nvmem cell list that are added to provider. However this design has some limitations when consumers want to assign name or connection id the nvmem cell instance, ex: via "nvmem-cell-names" or id in nvmem_cell_get(id). Having a name associated with nvmem cell consumer instance will help provider drivers in performing post processing of nvmem cell data if required before data is seen by the consumers. This is pretty normal with some vendors storing nvmem cells like mac-address in a vendor specific data layouts that are not directly usable by the consumer drivers. With this patch nvmem cell will be created dynamically during nvmem_cell_get and destroyed in nvmem_cell_put, allowing consumers to associate name with nvmem cell consumer instance. With this patch a new struct nvmem_cell_entry replaces struct nvmem_cell for storing nvmem cell information within the core. This patch does not change nvmem-consumer interface based on nvmem_cell. Tested-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211013131957.30271-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2021-10-13 14:19:55 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: fix commenting style Remove a redundant '*/' as pointed out by checkpatch. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:23 -07:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: core: remove regmap dependency nvmem uses regmap_raw_read/write apis to read/write data from providers, regmap raw apis stopped working with recent kernels which removed raw accessors on mmio bus. This resulted in broken nvmem for providers which are based on regmap mmio bus. This issue can be fixed temporarly by moving to other regmap apis, but we might hit same issue in future. Moving to interfaces based on read/write callbacks from providers would be more robust. This patch removes regmap dependency from nvmem and introduces read/write callbacks from the providers. Without this patch nvmem providers like qfprom based on regmap mmio bus would not work. Reported-by: Rajendra Nayak <rjendra@qti.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2016-04-24 20:28:05 +01:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

remove lots of IS_ERR_VALUE abuses Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2016-05-27 23:23:25 +02:00

nvmem: Add nvmem_device based consumer apis. This patch adds read/write apis which are based on nvmem_device. It is common that the drivers like omap cape manager or qcom cpr driver to access bytes directly at particular offset in the eeprom and not from nvmem cell info in DT. These driver would need to get access to the nvmem directly, which is what these new APIS provide. These wrapper apis would help such users to avoid code duplication in there drivers and also avoid them reading a big eeprom blob and parsing it internally in there driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:45 +01:00

nvmem: add support for cell info Add new structs and routines allowing users to define nvmem cells from machine code. This global list of entries is parsed when a provider is registered and cells are associated with the relevant nvmem_device struct. A possible improvement for the future is to allow users to register cell tables after the nvmem provider has been registered by updating the cell list at each call to nvmem_(add|del)_cell_table(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:15 -07:00

nvmem: add support for cell lookups from machine code Add a way for machine code users to associate devices with nvmem cells. This restores the support for non-DT systems but following a different approach. Cells must now be associated with devices using provided routines and data structures before they can be retrieved using nvmem_cell_get(). It's still possible to define cells statically in nvmem_config but cells created this way still need to be associated with consumers using lookup entries. Note that nvmem_find() must be moved higher in the source file as we want to call it from __nvmem_device_get() for devices that don't have a device node. The signature of __nvmem_device_get() is also changed as it's no longer used to retrieve cells. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:17 -07:00

nvmem: provide nvmem_dev_name() Kernel users don't have any means of checking the names of nvmem devices. Add a routine that returns the name of the nvmem provider. This will be useful for future nvmem notifier subscribers - otherwise they can't check what device is being added/removed. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2018-09-21 06:40:03 -07:00

nvmem: core: add nvmem_dev_size() helper 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 <rafal@milecki.pl> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20231221173421.13737-2-zajec5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-21 18:34:17 +01:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

nvmem: core: Rework layouts to become regular devices Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2023-12-15 11:15:32 +00:00

nvmem: Add a simple NVMEM framework for nvmem providers This patch adds just providers part of the framework just to enable easy review. Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they all had to duplicate pretty much the same code to register a sysfs file, allow in-kernel users to access the content of the devices they were driving, etc. This was also a problem as far as other in-kernel users were involved, since the solutions used were pretty much different from on driver to another, there was a rather big abstraction leak. This introduction of this framework aims at solving this. It also introduces DT representation for consumer devices to go get the data they require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from the nvmems. Having regmap interface to this framework would give much better abstraction for nvmems on different buses. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

2015-07-27 12:13:19 +01:00

2243 lines 51 KiB Raw Normal View History

2243 lines

51 KiB

Raw Normal View History