From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
<arm-scmi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 7/8] firmware: arm_scmi: transport: Add ACPI PCC transport
Date: Mon, 20 Oct 2025 18:37:31 +0100 [thread overview]
Message-ID: <20251020183731.000023fa@huawei.com> (raw)
In-Reply-To: <20251017-acpi_scmi_pcc-v1-7-0adbab7709d9@arm.com>
On Fri, 17 Oct 2025 14:23:50 +0100
Sudeep Holla <sudeep.holla@arm.com> wrote:
> Introduce a new SCMI transport that uses ACPI PCCT (PCC) subspaces via
> the Linux PCC mailbox layer. The driver parses ACPI _DSD data to map
> protocols to PCC subspace UIDs, supports shared TX/RX channels, and
> optionally sets up a P2A channel for notifications.
>
> Key points:
> - new CONFIG_ARM_SCMI_TRANSPORT_PCC option
> - integration with SCMI core via scmi_desc and transport ops
> - response/notification fetch from PCC shared memory header/payload
> - ACPI device matching and registration via the ACPI transport macro
>
> This enables SCMI to be exercised over PCC on ACPI platforms.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Hi Sudeep,
Just a very quick look in what is definitely a drive by style review
A few things below.
> diff --git a/drivers/firmware/arm_scmi/transports/pcc.c b/drivers/firmware/arm_scmi/transports/pcc.c
> new file mode 100644
> index 000000000000..39ef83e2dfd4
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/transports/pcc.c
> @@ -0,0 +1,390 @@
> +
> +/**
> + * struct scmi_pcc - Structure representing a SCMI mailbox transport
> + *
> + * @cl: Mailbox Client
> + * @pchan: Transmit/Receive PCC/mailbox channel
> + * @cinfo: SCMI channel info
> + * @shmem: Transmit/Receive shared memory area
run kernel-doc over the file (shmem doesn't exist).
> + */
> +struct scmi_pcc {
> + struct mbox_client cl;
> + struct pcc_mbox_chan *pchan;
> + struct scmi_chan_info *cinfo;
> +};
> +
> +static int acpi_scmi_dsd_parse_protocol_subpackage(const union acpi_object *obj,
> + int prot_id)
> +{
> + u32 uid;
> + int idx, ret = 0;
> + struct pcc_transport *p;
> + unsigned int pkg_cnt = obj->package.count;
> +
> + if (pkg_cnt > 2) {
> + pr_warn("Only 2 channels: one Tx and one Rx needed\n");
> + return -EINVAL;
> + }
> +
> + for (idx = 0; idx < pkg_cnt; idx++) {
> + union acpi_object *pack = &obj->package.elements[idx];
> +
> + /* Flags(pack->package.elements[1]) must be always 0 for now */
> + uid = pack->package.elements[0].integer.value;
> + hash_for_each_possible(pcc_id_hash, p, hnode, uid) {
> + if (p->flags & SCMI_TRANSPORT_SHARED_CHANNEL) {
> + pr_info("Invalid! %d channel is shared\n",
> + p->pcc_ss_id);
> + ret = -EINVAL;
This breaks out of the hash_for_each_... but the outer loop might continue
and it's just possible pass. however we leave ret set. Why not bail out
on first error? E.g. return -EINVAL; here.
> + break;
> + }
> + p->protocol_id = prot_id;
> + }
> + }
> +
> + return ret;
> +}
> +#ifdef CONFIG_ACPI
This is the bit I'd avoid by not use ACPI_PTR() in the earlier patch.
> +static const struct acpi_device_id scmi_acpi_ids[] = {
> + {"ARML0001", 0},
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, scmi_acpi_ids);
> +#endif
> +
> +DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(scmi_pcc, scmi_pcc_driver,
> + scmi_pcc_desc, scmi_acpi_ids, core);
> +module_platform_driver(scmi_pcc_driver);
> +
> +MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>");
> +MODULE_DESCRIPTION("SCMI ACPI PCC Transport driver");
> +MODULE_LICENSE("GPL");
>
next prev parent reply other threads:[~2025-10-20 17:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 13:23 [PATCH 0/8] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport Sudeep Holla
2025-10-17 13:23 ` [PATCH 1/8] firmware: arm_scmi: Set fwnode for the genrated SCMI platform device Sudeep Holla
2025-10-20 17:07 ` Jonathan Cameron
2025-10-21 9:03 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 2/8] firmware: arm_scmi: Extend transport driver macro to support ACPI Sudeep Holla
2025-10-20 17:11 ` Jonathan Cameron
2025-10-21 9:06 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 3/8] firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI core Sudeep Holla
2025-10-20 17:29 ` Jonathan Cameron
2025-10-21 9:26 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 4/8] firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absent Sudeep Holla
2025-10-17 13:23 ` [PATCH 5/8] firmware: arm_scmi: Pass protocol ID to chan_available() transport callback Sudeep Holla
2025-10-17 13:23 ` [PATCH 6/8] firmware: arm_scmi: Refactor protocol device creation logic Sudeep Holla
2025-10-17 13:23 ` [PATCH 7/8] firmware: arm_scmi: transport: Add ACPI PCC transport Sudeep Holla
2025-10-20 8:20 ` Dan Carpenter
2025-10-20 8:47 ` Sudeep Holla
2025-10-20 17:37 ` Jonathan Cameron [this message]
2025-10-21 9:30 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 8/8] firmware: arm_scmi: Initialise all protocol devices and transport channels Sudeep Holla
2025-11-05 11:49 ` [PATCH 0/8] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport Punit Agrawal
2025-11-26 14:31 ` Sudeep Holla
2025-12-03 11:04 ` Punit Agrawal
2025-12-03 15:21 ` Sudeep Holla
2025-12-04 18:25 ` Punit Agrawal
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=20251020183731.000023fa@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=sudeep.holla@arm.com \
/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.