[...]
> >
> > + /*
> > + * If this is the first gpio_request for the bank,
> > + * enable the bank module.
> > + */
> > + if (!bank->mod_usage) {
> > + if (IS_ERR_VALUE(pm_runtime_get_sync(bank->dev) < 0)) {
> > + dev_err(bank->dev, "%s: GPIO bank %d "
> > + "pm_runtime_get_sync failed\n",
> > + __func__, bank->id);
> > + return -EINVAL;
>
>
> Must spin_unlock_irqrestore() first.
Yes.
>
> > + }
> > +
> > + /* Initialize the gpio bank registers to init time value */
> > + omap_gpio_mod_init(bank);
>
> omap_gpio_mod_init calls mpuio_init calls platform_driver_register
> which can't be called in an IRQs off and spinlocked atomic context,
> for example, device_private_init calls kzalloc with GFP_KERNEL.
Right! The present form of *_mod_init() is not suitable here.
>
> Concurrency protection for this will need to happen prior to the
> spinlock (assuming it really does need to be an IRQ saving spinlock
> and not a mutex). Possibly a new mutex is needed to protect the
> check for first usage and init'ing the bank (and blocking a racing
> second caller until the init is done).
I looked at the implementation once again with the comments at background.
There are gaps which require fixing. Thanks.
>
> The omap_gpio_mod_init may be unbalanced with the code performed below
> on last free of a GPIO for the bank? If all GPIOs are freed and then
> a new GPIO used, does omap_gpio_mod_init do the right thing? Need a
> separate flag to indicate whether one-time init has ever been
> performed, vs. needing runtime PM enable/disable?
Yes, there is imbalance. I am re-looking and fixing.
--
Tarun
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
