All of lore.kernel.org
 help / color / mirror / Atom feed
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 2/8] firmware: arm_scmi: Extend transport driver macro to support ACPI
Date: Mon, 20 Oct 2025 18:11:06 +0100	[thread overview]
Message-ID: <20251020181106.0000724f@huawei.com> (raw)
In-Reply-To: <20251017-acpi_scmi_pcc-v1-2-0adbab7709d9@arm.com>

On Fri, 17 Oct 2025 14:23:45 +0100
Sudeep Holla <sudeep.holla@arm.com> wrote:

> Extend the SCMI transport driver helper to also support ACPI-based
> systems. Introduce an internal helper macro that accepts both OF and
> ACPI match tables, and expose two wrappers:
> 
>   - DEFINE_SCMI_TRANSPORT_DRIVER(...)      -> DT/OF wrapper (unchanged ABI)
>   - DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(...) -> ACPI wrapper
> 
> For ACPI, the generated platform_driver now sets .acpi_match_table via
> ACPI_PTR() so that builds without CONFIG_ACPI remain safe (becomes NULL).
In general it doesn't normally matter if ACPI_PTR() isn't used.

What specifically is this preventing?  If CONFIG_ACPI isn't set then we'll never
use those paths anyway.  Using ACPI_PTR() tends to need ifdef magic or
__maybe_unused markings that are rarely worth the effort for these tiny
tables.

> The spawned platform_device inherits the parent device’s ACPI companion
> to ensure proper firmware-node association (i.e.subsequent lookups or
> fwnode use see the correct firmware node).
> 
> This keeps existing DT users unchanged and continues to function as
> expected while allowing transports to be probed using the structure
> `acpi_device_id` tables on ACPI platforms.
> 
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/firmware/arm_scmi/common.h | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 911941e6885d..d038fec72360 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -9,6 +9,7 @@
>  #ifndef _SCMI_COMMON_H
>  #define _SCMI_COMMON_H
>  
> +#include <linux/acpi.h>
>  #include <linux/bitfield.h>
>  #include <linux/completion.h>
>  #include <linux/device.h>
> @@ -453,7 +454,8 @@ struct scmi_transport {
>  	struct scmi_transport_core_operations **core_ops;
>  };
>  
> -#define DEFINE_SCMI_TRANSPORT_DRIVER(__tag, __drv, __desc, __match, __core_ops)\
> +#define __DEFINE_SCMI_TRANSPORT_DRIVER(__tag, __drv, __desc, __of_match,       \
> +					__acpi_match, __core_ops)	       \
>  static void __tag##_dev_free(void *data)				       \
>  {									       \
>  	struct platform_device *spdev = data;				       \
> @@ -474,6 +476,7 @@ static int __tag##_probe(struct platform_device *pdev)			       \
>  									       \
>  	device_set_of_node_from_dev(&spdev->dev, dev);			       \
>  	device_set_node(&spdev->dev, dev_fwnode(dev));			       \
> +	ACPI_COMPANION_SET(&spdev->dev, ACPI_COMPANION(dev));		       \
>  									       \
>  	strans.supplier = dev;						       \
>  	memcpy(&strans.desc, &(__desc), sizeof(strans.desc));		       \
> @@ -498,11 +501,18 @@ err:									       \
>  static struct platform_driver __drv = {					       \
>  	.driver = {							       \
>  		   .name = #__tag "_transport",				       \
> -		   .of_match_table = __match,				       \
> +		   .of_match_table = __of_match,			       \
> +		   .acpi_match_table = ACPI_PTR(__acpi_match),		       \
>  		   },							       \
>  	.probe = __tag##_probe,						       \
>  }
>  
> +#define DEFINE_SCMI_TRANSPORT_DRIVER(__tag, __drv, __desc, __match, __core_ops)\
> +	__DEFINE_SCMI_TRANSPORT_DRIVER(__tag, __drv, __desc, __match, NULL, __core_ops)
> +
> +#define DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(__tag, __drv, __desc, __match, __core_ops)\
> +	__DEFINE_SCMI_TRANSPORT_DRIVER(__tag, __drv, __desc, NULL, __match, __core_ops)
> +
>  void scmi_notification_instance_data_set(const struct scmi_handle *handle,
>  					 void *priv);
>  void *scmi_notification_instance_data_get(const struct scmi_handle *handle);
> 


  reply	other threads:[~2025-10-20 17:11 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 [this message]
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
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=20251020181106.0000724f@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.