On Sun, Jul 22, 2018 at 01:04:11PM -0700, David Miller wrote:
> From: Uwe Kleine-König
> Date: Sun, 22 Jul 2018 21:00:35 +0200
>
> > On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
> >> From: Uwe Kleine-König
> >> Date: Fri, 20 Jul 2018 11:53:15 +0200
> >>
> >> > free_irq() waits
From: Uwe Kleine-König
Date: Sun, 22 Jul 2018 21:00:35 +0200
> On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
>> From: Uwe Kleine-König
>> Date: Fri, 20 Jul 2018 11:53:15 +0200
>>
>> > free_irq() waits until all handlers for this IRQ have completed. As the
>> > relevant handler (
Hello,
On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote:
> From: Uwe Kleine-König
> Date: Fri, 20 Jul 2018 11:53:15 +0200
>
> > free_irq() waits until all handlers for this IRQ have completed. As the
> > relevant handler (mv88e6xxx_g1_irq_thread_fn()) takes the chip's reg_lock
> > it
From: Uwe Kleine-König
Date: Fri, 20 Jul 2018 11:53:15 +0200
> free_irq() waits until all handlers for this IRQ have completed. As the
> relevant handler (mv88e6xxx_g1_irq_thread_fn()) takes the chip's reg_lock
> it might never return if the thread calling free_irq() holds this lock.
>
> For the
free_irq() waits until all handlers for this IRQ have completed. As the
relevant handler (mv88e6xxx_g1_irq_thread_fn()) takes the chip's reg_lock
it might never return if the thread calling free_irq() holds this lock.
For the same reason kthread_cancel_delayed_work_sync() in the polling case
must
