linux-kernel - Re: [PATCH V4 1/3] iommu/arm-smmu-v3: Add device-tree support for CMDQV driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7c69e9c-6af4-468a-88ed-fb8829afb92e@arm.com>
Date: Wed, 10 Dec 2025 12:39:49 +0000
From: Robin Murphy <robin.murphy@....com>
To: Ashish Mhetre <amhetre@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
Cc: oe-kbuild-all@...ts.linux.dev, thierry.reding@...il.com,
 jonathanh@...dia.com, vdumpa@...dia.com, jgg@...pe.ca,
 linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-tegra@...r.kernel.org, joro@...tes.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, kernel test robot <lkp@...el.com>,
 will@...nel.org
Subject: Re: [PATCH V4 1/3] iommu/arm-smmu-v3: Add device-tree support for
 CMDQV driver

On 2025-12-10 5:19 am, Ashish Mhetre wrote:
[...]
> Hi Robin, Nic,
> We removed ACPI dependency in Kconfig but driver still depends
> on ACPI for these functions. I will be protecting ACPIspecific
> tegra241-cmdqv code under CONFIG_ACPI similar to what is done
> in arm-smmu-v3 driver. Is this the correct thing to do or do you
> have any other suggestions?

Yes, when I commented that "depends on ACPI || OF" was functionally the 
same as just removing "depends on ACPI", I didn't mean to suggest that 
wasn't necessarily a genuine dependency still.

I guess if you can wrap the ACPI-specific functions in a single #ifdef 
block that's reasonable, however I do now wonder whether things couldn't 
be factored out a bit more - if it's a standard DSDT/SSDT namespace 
device, shouldn't there also be a corresponding platform device created 
for it, which we could look up instead of delving directly into the _CRS 
of the ACPI node itself? (not sure off-hand if there's a straightforward 
inverse of ACPI_COMPANION()...)

Thanks,
Robin.