Re: [PATCH v3 2/9] firmware: arm_scmi: Extend transport driver macro to support ACPI

[Sudeep Holla <sudeep.holla@kernel.org>]

On Mon, Aug 24, 2026 at 10:04:31AM -0700, Jonathan Cameron wrote:
> On Thu, 13 Aug 2026 12:32:57 +0100
> Sudeep Holla <sudeep.holla@kernel.org> wrote:
> 
> > Extend the SCMI transport driver helper to 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(...) for DT/OF transports
> >   - DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(...) for ACPI transports
> > 
> > For ACPI, set the generated platform_driver .acpi_match_table via
> > ACPI_PTR().
> 
> ACPI_PTR() is often more trouble that it is worth because of need
> to guard the tables if they turn up in code where ACPI might not be present.
> 
> Now if someone fancied doing the work to make it work like pm_ptr()
> then that would nicer.  That one lets the compiler both see the stuff beyond
> the pointer, but also do dead code removal on it later.
> 
> Anyhow, doesn't actually matter either way here because you only use that
> with a non NULL pointer in a driver that is ACPI only.
> 
> If you really want to do it, maybe pair with of_match_ptr() but
> that one is even worse as maybe some will be having fun with SCMI and
> PRP0001.
> 

Agree with your analysis.

> Anyhow, random diversion aside, it makes no difference in practice.
> 

I just had to use it to keep build bots happy IIRC.

> > The ACPI wrapper relies on the firmware-node propagation
> > provided by the preceding change so fwnode lookups on the spawned
> > platform device see the correct firmware description.
> > 
> > Keep existing DT users unchanged while allowing transports to be probed
> > using struct acpi_device_id tables on ACPI platforms.
> > 
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> 

Thanks!

-- 
Regards,
Sudeep