Messages in this thread | | | Subject | Re: [PATCH 1/2] regmap: teach regmap to use raw spinlocks if requested in the config | From | Rasmus Villemoes <> | Date | Mon, 30 Aug 2021 13:02:33 +0200 |
| |
On 27/08/2021 01.01, Thomas Gleixner wrote: > On Wed, Aug 25 2021 at 23:50, Vladimir Oltean wrote: > >> 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. > > What's reasonable about that? > > What exactly prevents the regmap locking to use a raw spinlock > unconditionally?
Perhaps this:
/* * When we write in fast-paths with regmap_bulk_write() don't allocate * scratch buffers with sleeping allocations. */ if ((bus && bus->fast_io) || config->fast_io) map->alloc_flags = GFP_ATOMIC; else map->alloc_flags = GFP_KERNEL;
i.e. the regmap code can actually do allocations under whatever internal lock it uses. So ISTM that any regmap that uses a raw_spinlock (whether unconditionally or via Vladimir's opt-in) cannot be used with regmap_bulk_write().
ISTM using regmap for mmio makes things more complicated than necessary.
Rasmus
| |