Since commit cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when
calling regmap_attach_dev"), the following debugfs error is seen
on i.MX boards:
debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
In the attempt to fix the memory leak, the above commit added a NULL check
for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL
and then the new name is allocated via kasprintf().
For the second debugfs entry, map->debugfs_name() is no longer NULL, so
it will keep using the old entry name and the duplicate name error is seen.
Quoting Mark Brown:
"That means that if the device gets freed we'll end up with the old debugfs
file hanging around pointing at nothing.
...
To be more explicit this means we need a call to regmap_debugfs_exit()
which will clean up all the existing debugfs stuff before we loose
references to it."
Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix
the problem.
Tested on i.MX6Q and i.MX6SX boards.
Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The ls-extirq irqchip driver accesses regmap inside its implementation of the struct irq_chip :: irq_set_type method, and currently regmap only knows to lock using normal spinlocks. But the method above wants raw spinlock context, so this isn't going to work and triggers a "[ BUG: Invalid wait context ]" splat. The best we can do given the arrangement of the code is to patch regmap and the syscon driver: regmap to support raw spinlocks, and syscon to request them on behalf of its ls-extirq consumer. Link: https://lore.kernel.org/lkml/20210825135438.ubcuxm5vctt6ne2q@skbuf/T/#u Vladimir Oltean (2): regmap: teach regmap to use raw spinlocks if requested in the config mfd: syscon: request a regmap with raw spinlocks for some devices drivers/base/regmap/internal.h | 4 ++++ drivers/base/regmap/regmap.c | 35 +++++++++++++++++++++++++++++----- drivers/mfd/syscon.c | 16 ++++++++++++++++ include/linux/regmap.h | 2 ++ 4 files changed, 52 insertions(+), 5 deletions(-) -- 2.25.1 base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5
Some drivers might access regmap in a context where a raw spinlock is held. An example is drivers/irqchip/irq-ls-extirq.c, which calls regmap_update_bits() from struct irq_chip :: irq_set_type, which is a method called by __irq_set_trigger() under the desc->lock raw spin lock. Since desc->lock is a raw spin lock and the regmap internal lock for mmio is a plain spinlock (which can become sleepable on RT), this is an invalid locking scheme and we get a splat stating that this is a "[ BUG: Invalid wait context ]". It seems reasonable for regmap to have an option use a raw spinlock too, so add that in the config such that drivers can request it. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210825205041.927788-2-vladimir.oltean@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
The reg_fields array fed to {devm_}regmap_field_bulk_alloc is currently
not const, which is not correct on semantics (the functions shouldn't
change reg_field contents) and prevents pre-defined const reg_field
array to be used.
As the implementation of this function doesn't change the content of it,
just add const to its prototype.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Link: https://lore.kernel.org/r/20210802063741.76301-1-icenowy@sipeed.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix checkpatch warnings:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: Jinchao Wang <wjc@cdjrlc.com>
Link: https://lore.kernel.org/r/20210628171907.63646-1-wjc@cdjrlc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the offset of register error log by using regmap_get_offset(). Signed-off-by: Jeongtae Park <jeongtae.park@gmail.com> Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for 7 bits register, 17 bits value type register formating. This is used, for example, by the Analog Devices ADMV1013/ADMV1014. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Andrei Drimbarean <andrei.drimbarean@analog.com> Message-Id: <20210526085223.14896-1-antoniu.miclaus@analog.com> Signed-off-by: Mark Brown <broonie@kernel.org>
Set regmap raw read/write from i2c quirks max read/write so regmap_raw_read/write can split the access into chunks Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210512135222.223203-1-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
_regmap_write can trigger a _regmap_select_page, which will call another _regmap_write that will be executed first, but the log shows the inverse order Also, keep consistency with _regmap_read which only logs in case of success Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20201112150217.459844-1-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>