linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: linux-i2c@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Wolfram Sang <wsa@the-dreams.de>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Mike Rapoport <mike@compulab.co.il>,
	Jean Delvare <khali@linux-fr.org>
Subject: rt-mutex usage in i2c
Date: Mon, 09 Mar 2015 14:43:28 +0100	[thread overview]
Message-ID: <54FDA380.8030405@linutronix.de> (raw)

I have two questions:

- em28xx_i2c_xfer() in drivers/media/usb/em28xx/em28xx-i2c.c takes a
  rt_mutex lock. This struct i2c_algorithm's ->master_xfer callback.
  Why does it take an extra lock since it looks to me that it is
  protected by struct i2c_adapter's bus_lock already.

- i2c_transfer() has this piece:
  2091                 if (in_atomic() || irqs_disabled()) {
  2092                         ret = i2c_trylock_adapter(adap);

  is this irqs_disabled() is what bothers me and should not be there.
  pxa does a spin_lock_irq() which would enable interrupts on return /
  too early.
  mxs has a wait_for_completion() which needs irqs enabled _and_ makes
  in_atomic() problematic, too. I have't checked other drivers but the
  commit, that introduced it, does not explain why it is required.
  So _should_ this be invoked from an interrupt handler (for instance),
  then it would record the wrong process as the lock owner. This isn't
  problematic unless on SMP the owner gets boosted because a process
  with a higher priority needs the lock.

Sebastian

             reply	other threads:[~2015-03-09 13:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 13:43 Sebastian Andrzej Siewior [this message]
2015-03-14 11:27 ` rt-mutex usage in i2c Wolfram Sang
2015-03-14 11:32   ` Wolfram Sang
2015-03-15  7:07     ` Mike Rapoport
     [not found]       ` <CABpLfoiQg1smiebL0=nWX4Sp1H+XD9VViUqGk13gRcfdAwkFoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-16 20:50         ` Sebastian Andrzej Siewior

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=54FDA380.8030405@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=khali@linux-fr.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=mike@compulab.co.il \
    --cc=umgwanakikbuti@gmail.com \
    --cc=wsa@the-dreams.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).