From: Thomas Gleixner <tglx@linutronix.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Christian Eggers <ceggers@arri.de>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/2] iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context
Date: Thu, 13 Aug 2020 14:19:57 +0200 [thread overview]
Message-ID: <877du2louq.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200813112741.grdytusuwrlskpwa@linutronix.de>
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:
> On 2020-08-13 11:46:30 [+0200], Lars-Peter Clausen wrote:
>> If you are running with forced IRQ threads the only thing that will then
>> happen in the actual hard IRQ context is the launching of the IRQ threads.
>> Th e IRQ handler of the device driver will run in a threaded IRQ.
>
> So if it is really just the wakeup of the IRQ-thread then it should be
> okay.
> One thing: iio_trigger_poll() may invoke iio_trigger_notify_done(). This
> would invoke trig->ops->try_reenable callback if available.
> I grepped and found
> - bma180_trig_try_reen()
> It appears to perform i2c_smbus_read_byte_data() and smbus sounds
> sleeping. I don't know if it attempts to acquire any spinlock_t but it
> will be wrong on RT.
It's wrong even on !RT. i2c reads cannot be invoked from hard interrupt
context.
next prev parent reply other threads:[~2020-08-13 12:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 7:53 [PATCH 1/2] iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context Lars-Peter Clausen
2020-08-13 7:53 ` [PATCH 2/2] iio: sysfs-trigger: Mark irq_work to expire in hardirq context Lars-Peter Clausen
2020-08-13 9:11 ` [PATCH 1/2] iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context Sebastian Andrzej Siewior
2020-08-13 9:46 ` Lars-Peter Clausen
2020-08-13 11:27 ` Sebastian Andrzej Siewior
2020-08-13 12:19 ` Thomas Gleixner [this message]
2020-08-13 14:55 ` Jonathan Cameron
2020-08-14 5:24 ` Lars-Peter Clausen
2020-08-14 10:30 ` Jonathan Cameron
2020-09-20 18:15 ` Jonathan Cameron
2020-09-21 7:17 ` Christian Eggers
2020-09-21 9:57 ` Jonathan Cameron
2020-09-21 12:27 ` Sebastian Andrzej Siewior
2020-09-21 13:32 ` Jonathan Cameron
2020-09-22 2:51 ` Andy Duan
2020-09-24 6:41 ` Sanchayan Maity
2020-09-24 8:54 ` Stefan Agner
2020-09-25 12:42 ` Jonathan Cameron
2020-10-02 14:10 ` Christian Eggers
2020-10-10 13:23 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877du2louq.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=ceggers@arri.de \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.