linux-kernel - Re: [RFC PATCH v1 11/38] KVM: arm64: CCA: register host tsm platform device

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: <yq5a347kmqzn.fsf@kernel.org>
Date: Wed, 15 Oct 2025 15:22:28 +0530
From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>, Jeremy Linton <jeremy.linton@....com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Dan Williams <dan.j.williams@...el.com>, linux-coco@...ts.linux.dev,
	kvmarm@...ts.linux.dev, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, aik@....com, lukas@...ner.de,
	Samuel Ortiz <sameo@...osinc.com>,
	Xu Yilun <yilun.xu@...ux.intel.com>,
	Suzuki K Poulose <Suzuki.Poulose@....com>,
	Steven Price <steven.price@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>
Subject: Re: [RFC PATCH v1 11/38] KVM: arm64: CCA: register host tsm
 platform device

Jason Gunthorpe <jgg@...pe.ca> writes:

> On Fri, Oct 10, 2025 at 07:10:58AM -0500, Jeremy Linton wrote:
>> > Yes, use faux_device if you need/want a struct device to represent
>> > something in the tree and it does NOT have any real platform resources
>> > behind it.  That's explicitly what it was designed for.
>> 
>> Right, but this code is intended to trigger the kmod/userspace module
>> loader.
>
> Faux devices are not intended to be bound, it says so right on the label:
>
>  * A "simple" faux bus that allows devices to be created and added
>  * automatically to it.  This is to be used whenever you need to create a
>  * device that is not associated with any "real" system resources, and do
>  * not want to have to deal with a bus/driver binding logic.  It is
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  * intended to be very simple, with only a create and a destroy function
>  * available.
>
> auxiliary_device is quite similar to faux except it is intended to be
> bound to drivers, supports module autoloading and so on.
>
> What you have here is the platform firmware provides the ARM SMC
> (Secure Monitor Call Calling Convention) interface which is a generic
> function call multiplexer between the OS and ARM firmware.
>
> Then we have things like the TSM subsystem that want to load a driver
> to use calls over SMC if the underlying platform firmware supports the
> RSI group of SMC APIs. You'd have a TSM subsystem driver that uses the
> RSI call group over SMC that autobinds when the RSI call group is
> detected when the SMC is first discovered.
>
> So you could use auxiliary_device, you'd consider SMC itself to be the
> shared HW block and all the auxiliary drivers are per-subsystem
> aspects of that shared SMC interface. It is not a terrible fit for
> what it was intended for at least.
>

IIUC, auxiliary_device needs a parent device, and the documentation
explains that it’s intended for cases where a large driver is split into
multiple dependent smaller ones.

If we want to use auxiliary_device for this case, what would serve as
the parent device?

-aneesh