mbox series

[0/2] hwspinlock: add the 'in_atomic' API

Message ID 1551974303-24542-1-git-send-email-fabien.dessenne@st.com (mailing list archive)
Headers show
Series hwspinlock: add the 'in_atomic' API | expand

Message

Fabien DESSENNE March 7, 2019, 3:58 p.m. UTC
In its current implementation, the hwspinlock framework relies on jiffies
to handle the timeout of the hwspin_lock_timeout_xxx() API.
In an atomic context (or more precisely when irq are disabled) jiffies does not
increase, which prevents the timeout to reach its target value (infinite loop).

Note that there is already an hwspinlock user that runs in atomic context
(drivers/irqchip/irq-stm32-exti.c) and that has to handle by itself the
timeout.

The first patch of the series completes the Documentation (the 'raw' API
is not documented), and the second patch provides with the 'in_atomic' API.

Fabien Dessenne (2):
  hwspinlock: document the hwspinlock 'raw' API
  hwspinlock: add the 'in_atomic' API

 Documentation/hwspinlock.txt         | 81 ++++++++++++++++++++++++++++++++++++
 drivers/hwspinlock/hwspinlock_core.c | 43 +++++++++++++------
 include/linux/hwspinlock.h           | 61 +++++++++++++++++++++++++--
 3 files changed, 169 insertions(+), 16 deletions(-)

Comments

Fabien DESSENNE May 13, 2019, 9:10 a.m. UTC | #1
Hi


Gentle reminder


Fabien

On 07/03/2019 4:58 PM, Fabien Dessenne wrote:
> In its current implementation, the hwspinlock framework relies on jiffies
> to handle the timeout of the hwspin_lock_timeout_xxx() API.
> In an atomic context (or more precisely when irq are disabled) jiffies does not
> increase, which prevents the timeout to reach its target value (infinite loop).
>
> Note that there is already an hwspinlock user that runs in atomic context
> (drivers/irqchip/irq-stm32-exti.c) and that has to handle by itself the
> timeout.
>
> The first patch of the series completes the Documentation (the 'raw' API
> is not documented), and the second patch provides with the 'in_atomic' API.
>
> Fabien Dessenne (2):
>    hwspinlock: document the hwspinlock 'raw' API
>    hwspinlock: add the 'in_atomic' API
>
>   Documentation/hwspinlock.txt         | 81 ++++++++++++++++++++++++++++++++++++
>   drivers/hwspinlock/hwspinlock_core.c | 43 +++++++++++++------
>   include/linux/hwspinlock.h           | 61 +++++++++++++++++++++++++--
>   3 files changed, 169 insertions(+), 16 deletions(-)
>
Bjorn Andersson June 30, 2019, 4:08 a.m. UTC | #2
On Thu 07 Mar 07:58 PST 2019, Fabien Dessenne wrote:

> In its current implementation, the hwspinlock framework relies on jiffies
> to handle the timeout of the hwspin_lock_timeout_xxx() API.
> In an atomic context (or more precisely when irq are disabled) jiffies does not
> increase, which prevents the timeout to reach its target value (infinite loop).
> 
> Note that there is already an hwspinlock user that runs in atomic context
> (drivers/irqchip/irq-stm32-exti.c) and that has to handle by itself the
> timeout.
> 
> The first patch of the series completes the Documentation (the 'raw' API
> is not documented), and the second patch provides with the 'in_atomic' API.
> 

Applied

Thanks,
Bjorn

> Fabien Dessenne (2):
>   hwspinlock: document the hwspinlock 'raw' API
>   hwspinlock: add the 'in_atomic' API
> 
>  Documentation/hwspinlock.txt         | 81 ++++++++++++++++++++++++++++++++++++
>  drivers/hwspinlock/hwspinlock_core.c | 43 +++++++++++++------
>  include/linux/hwspinlock.h           | 61 +++++++++++++++++++++++++--
>  3 files changed, 169 insertions(+), 16 deletions(-)
> 
> -- 
> 2.7.4
>