From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Cc: mika.westerberg@linux.intel.com, linux-i2c@vger.kernel.org,
linux-acpi@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v3] i2c: acpi: Unbind mux adapters before delete
Date: Mon, 4 Mar 2024 10:08:23 +0100 [thread overview]
Message-ID: <ZeWPh3asA0rSTJ92@ninjato> (raw)
In-Reply-To: <20240304000355.2614421-1-hamish.martin@alliedtelesis.co.nz>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On Mon, Mar 04, 2024 at 01:03:55PM +1300, Hamish Martin wrote:
> There is an issue with ACPI overlay table removal specifically related
> to I2C multiplexers.
>
> Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an
> existing I2C bus. When this table is loaded we see the creation of a
> device for the overall PCA9548 chip and 8 further devices - one
> i2c_adapter each for the mux channels. These are all bound to their
> ACPI equivalents via an eventual invocation of acpi_bind_one().
>
> When we unload the SSDT overlay we run into the problem. The ACPI
> devices are deleted as normal via acpi_device_del_work_fn() and the
> acpi_device_del_list.
>
> However, the following warning and stack trace is output as the
> deletion does not go smoothly:
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-03-04 9:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 0:03 [PATCH v3] i2c: acpi: Unbind mux adapters before delete Hamish Martin
2024-03-04 9:08 ` Wolfram Sang [this message]
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=ZeWPh3asA0rSTJ92@ninjato \
--to=wsa+renesas@sang-engineering.com \
--cc=andi.shyti@kernel.org \
--cc=hamish.martin@alliedtelesis.co.nz \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=stable@vger.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 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.