From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Luca Ceresoli <luca.ceresoli@bootlin.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
Wolfram Sang <wsa@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Cosmin Tanislav <demonsingur@gmail.com>,
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Subject: Re: [PATCH 2/3] i2c: atr: Fix lockdep for nested ATRs
Date: Fri, 22 Nov 2024 11:24:10 +0200 [thread overview]
Message-ID: <Z0BNug5KZp74t4MA@smile.fi.intel.com> (raw)
In-Reply-To: <20241122-i2c-atr-fixes-v1-2-62c51ce790be@ideasonboard.com>
On Fri, Nov 22, 2024 at 09:51:39AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> When we have an ATR, and another ATR as a subdevice of the first ATR,
> we get lockdep warnings for the i2c_atr.lock and
> i2c_atr_chan.orig_addrs_lock. This is because lockdep uses a static key
> for the locks, and doesn't see the locks of the separate ATR instances
> as separate.
...
> + lockdep_register_key(&atr->lock_key);
> mutex_init(&atr->lock);
> + lockdep_set_class(&atr->lock, &atr->lock_key);
mutext_init_with_key()
...
> + lockdep_register_key(&chan->orig_addrs_lock_key);
> mutex_init(&chan->orig_addrs_lock);
> + lockdep_set_class(&chan->orig_addrs_lock, &chan->orig_addrs_lock_key);
Ditto.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-11-22 9:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 7:51 [PATCH 0/3] i2c: atr: A few i2c-atr fixes Tomi Valkeinen
2024-11-22 7:51 ` [PATCH 1/3] i2c: atr: Allow unmapped addresses from nested ATRs Tomi Valkeinen
2024-11-22 7:51 ` [PATCH 2/3] i2c: atr: Fix lockdep for " Tomi Valkeinen
2024-11-22 9:24 ` Andy Shevchenko [this message]
2024-11-25 12:13 ` kernel test robot
2024-11-22 7:51 ` [PATCH 3/3] i2c: atr: Fix client detach Tomi Valkeinen
2024-11-22 9:25 ` Andy Shevchenko
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=Z0BNug5KZp74t4MA@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=demonsingur@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tomi.valkeinen+renesas@ideasonboard.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@kernel.org \
/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