[PATCH v3 4/9] firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absent

[Sudeep Holla]

On Wed, Sep 02, 2026 at 09:03:02AM +0100, Sudeep Holla wrote:
> On Mon, Aug 24, 2026 at 10:43:37AM -0700, Jonathan Cameron wrote:
> > On Thu, 13 Aug 2026 12:32:59 +0100
> > Sudeep Holla <sudeep.holla at kernel.org> wrote:
> > 
> > > scmi_debugfs_common_setup() uses the "compatible" property to
> > > populate the debugfs transport type string. ACPI-described SCMI
> > > devices do not provide that DT property, so the string remains
> > > NULL and debugfs setup falls through the allocation failure path.
> > > 
> > > Check the property lookup result and use the ACPI HID as the
> > > fallback transport type when an ACPI companion is present.
> > > 
> > > All supported DT SCMI platforms are expected to provide "compatible",
> > > so the non-ACPI fallback is not needed for normal DT operation. Keep
> > > the explicit "unknown" fallback anyway to avoid passing NULL to
> > > kstrdup() if that assumption is ever violated.
> > > 
> > > Signed-off-by: Sudeep Holla <sudeep.holla at kernel.org>
> > Can drop some complexity in here and rely on the stubs in acpi.h a little more.
> > 
> > > ---
> > >  drivers/firmware/arm_scmi/driver.c | 16 ++++++++++++++--
> > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > index 9014723e0f7f..9ad827c6a9ab 100644
> > > --- a/drivers/firmware/arm_scmi/driver.c
> > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > @@ -16,6 +16,7 @@
> > >  
> > >  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > >  
> > > +#include <linux/acpi.h>
> > >  #include <linux/bitmap.h>
> > >  #include <linux/cleanup.h>
> > >  #include <linux/debugfs.h>
> > > @@ -3063,6 +3064,15 @@ static void scmi_debugfs_common_cleanup(void *d)
> > >  	kfree(dbg->type);
> > >  }
> > >  
> > > +static const char *scmi_acpi_device_hid(struct acpi_device *adev)
> > > +{
> > > +#ifdef CONFIG_ACPI
> > 
> > Hmm. Ugly that acpi_device_id returns an empty string.
> > 
> > However given when !CONFIG_ACPI the stub for ACPI_COMPANION(dev) is
> > NULL.  You don't need this dance anyway.
> > 
> 
> That was exactly my thoughts initially until builder bots complained.
> But acpi_device_hid() is defined only for CONFIG_ACPI, though I can
> handle it runtime, I need to define acpi_device_hid() as NULL for
> !CONFIG_ACPI as alternative.
> 

Scratch that, I need to dig the build failure and understand it better.
I think including acpi_bus.h caused some issue which I don't like as
acpi_bus.h must be for core acpi support code. We may need to move
acpi_device_hid() out of there.

-- 
Regards,
Sudeep