From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: Lukas Wunner <lukas@wunner.de>,
Heiner Kallweit <hkallweit1@gmail.com>,
Keith Busch <kbusch@kernel.org>, Wolfram Sang <wsa@kernel.org>,
Jean Delvare <jdelvare@suse.de>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [bug report] lockdep WARN at PCI device rescan
Date: Fri, 24 Nov 2023 17:22:57 +0200 [thread overview]
Message-ID: <ZWC_0eG2UBMKAD3C@smile.fi.intel.com> (raw)
In-Reply-To: <eaawoi5jqrwnzq3scgltqxj47faywztn4lbpkz4haugxvgu5df@koy3qciquklu>
On Fri, Nov 24, 2023 at 10:49:45AM +0000, Shinichiro Kawasaki wrote:
> On Nov 14, 2023 / 19:58, Andy Shevchenko wrote:
...
> I created a patch below and confirmed it avoided the lockdep WARN. The
> i2c-i801 probe was ok at system boot.
Another possible solution I was thinking about is to have a local cache,
so, make p2sb.c to be called just after PCI enumeration at boot time
to cache the P2SB device's bar, and then cache the bar based on the device
in question at the first call. Yet it may not remove all theoretical /
possible scenarios with dead lock (taking into account hotpluggable
devices), but won't fail the i801 driver in the above use case IIUC.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-11-24 15:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 6:54 [bug report] lockdep WARN at PCI device rescan Shinichiro Kawasaki
2023-11-14 10:16 ` Wolfram Sang
2023-11-14 10:47 ` Heiner Kallweit
2023-11-14 12:04 ` Andy Shevchenko
2023-11-14 15:57 ` Lukas Wunner
2023-11-14 16:11 ` Andy Shevchenko
2023-11-14 17:58 ` Andy Shevchenko
2023-11-24 10:49 ` Shinichiro Kawasaki
2023-11-24 15:22 ` Andy Shevchenko [this message]
2023-11-28 7:45 ` Shinichiro Kawasaki
2023-11-29 11:17 ` Lukas Wunner
[not found] ` <ZWdBnMTOq9wIt9L-@smile.fi.intel.com>
2023-11-29 13:53 ` Andy Shevchenko
2023-11-30 7:30 ` Shinichiro Kawasaki
2023-11-30 9:36 ` Lukas Wunner
2023-12-01 0:37 ` Bjorn Helgaas
2023-12-01 10:46 ` Shinichiro Kawasaki
2023-11-30 15:19 ` Andy Shevchenko
2023-12-01 10:34 ` Shinichiro Kawasaki
2023-11-24 17:30 ` Heiner Kallweit
2023-11-28 10:16 ` Shinichiro Kawasaki
2023-11-29 11:30 ` Lukas Wunner
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=ZWC_0eG2UBMKAD3C@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=hkallweit1@gmail.com \
--cc=jdelvare@suse.de \
--cc=kbusch@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=shinichiro.kawasaki@wdc.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