talos-obmc-linux/drivers/nvmem/core.c, branch dev-4.13

nvmem: core: add locking to nvmem_find_cell

2017-06-09T10:08:27+00:00

Adding entries to nvmem_cells and deleting entries from it is protected by nvmem_cells_mutex. Therefore this mutex should also protect iterating over the list. Signed-off-by: Heiner Kallweit Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: Call put_device() in nvmem_unregister()

2017-06-09T10:08:27+00:00

Call put_device() in nvmem_unregister() to make sure nvmem_release gets called freeing up allocated resources. Cc: cphealy@gmail.com Cc: Srinivas Kandagatla Cc: Maxime Ripard Signed-off-by: Andrey Smirnov Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: fix leaks on registration errors

2017-06-09T10:08:27+00:00

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 # 4.3 Cc: Andrew Lunn Cc: Srinivas Kandagatla Cc: Mika Westerberg Signed-off-by: Johan Hovold Acked-by: Andrey Smirnov Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: Allow allocating several anonymous nvmem devices

2017-04-08T15:51:48+00:00

Currently the nvmem core expect the config to provide a name and ID that are then used to create the device name. When no device name is given 'nvmem' is used. However if there is several such anonymous devices they all get named 'nvmem0', which doesn't work. To fix this problem use the ID from the config only when the config also provides a name. When no name is provided take the uinque ID of the nvmem device instead. Signed-off-by: Aban Bedel Reviewed-by: Moritz Fischer Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: Allow getting nvmem cell with a NULL cell id

2017-01-25T10:49:39+00:00

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 Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: Correct a bunch of function documentations

2017-01-25T10:49:39+00:00

Correct the documentation for arguments to a number of functions. Signed-off-by: Vivek Gautam Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: core: Allow ignoring length when reading a cell

2017-01-25T10:49:39+00:00

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 Reviewed-by: Stephen Boyd Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

nvmem: fix nvmem_cell_read() return type doc

2017-01-04T17:22:47+00:00

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 Fixes: a6c50912508d ("nvmem: Declare nvmem_cell_read() consistently") Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11+00:00

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 Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

nvmem: core: remove regmap dependency

2016-05-01T21:01:00+00:00

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 Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman