Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: arm-scmi@vger.kernel.org,
	Hans de Goede <johannes.goede@oss.qualcomm.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	NXP S32 Linux Team <s32@nxp.com>,
	Linus Walleij <linusw@kernel.org>,
	linux-gpio@vger.kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH 0/4] firmware: arm_scmi: Some fixes to address conflicts with fw_devlink
Date: Sat, 3 Oct 2026 21:09:48 +0800	[thread overview]
Message-ID: <asD+nBI+yq1F0MOP@shlinux89> (raw)
In-Reply-To: <20261002-scmi_bus_fixes-v1-0-8695cbab3fe7@kernel.org>

On Fri, Oct 02, 2026 at 10:36:29AM +0100, Sudeep Holla wrote:
>Peng’s [1] identified the problem of multiple SCMI devices sharing one
>protocol fwnode. His [2] shows the consequence: the first device owns
>the fwnode but does not bind, so fw_devlink can leave consumers deferred
>even when another device binds successfully.
>
>This four-patch series reduces those cases within SCMI. It prevents
>protocol device creation in exclusive raw mode, stops treating core
>created standard devices as driver owned requests, and makes the i.MX
>pinctrl driver match the standard `pinctrl` device instead of creating
>a second device for the same fwnode. It also omits the `perf` device
>when the firmware node does not describe a performance domain provider,
>without changing `cpufreq` device creation. IIO/HWMON don't have any
>fw_devlink dependency and having two devices shouldn't be an issue.
>
>These changes address the SCMI cases above; they do not provide a
>general driver core solution for devices that share a fwnode.
>
>Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
>[1] https://lore.kernel.org/all/20250120-scmi-fwdevlink-v2-0-3af2fa37dbac@nxp.com
>[2] https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com
>
>---
>Sudeep Holla (4):
>      firmware: arm_scmi: Avoid protocol devices in exclusive raw mode
>      firmware: arm_scmi: Skip requests for standard protocol devices
>      pinctrl: imx: Match the standard SCMI pinctrl device
>      firmware: arm_scmi: Skip unused performance-domain devices
>

Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK

Thanks
Peng

      parent reply	other threads:[~2026-10-03 13:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02  9:36 [PATCH 0/4] firmware: arm_scmi: Some fixes to address conflicts with fw_devlink Sudeep Holla
2026-10-02  9:36 ` [PATCH 3/4] pinctrl: imx: Match the standard SCMI pinctrl device Sudeep Holla
2026-10-03 13:10   ` Peng Fan
2026-10-07 10:32   ` Linus Walleij
2026-10-07 14:22     ` Sudeep Holla
2026-10-03 13:09 ` Peng Fan [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=asD+nBI+yq1F0MOP@shlinux89 \
    --to=peng.fan@oss.nxp.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=johannes.goede@oss.qualcomm.com \
    --cc=kernel@pengutronix.de \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=s32@nxp.com \
    --cc=sudeep.holla@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