Re: [PATCH RFC 0/3] firmware: arm_firme: introduce FIRME support for host attestation

[Yeoreum Yun <yeoreum.yun@arm.com>]

On Tue, Oct 20, 2026 at 11:58:06AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2026 at 03:43:47PM +0100, Yeoreum Yun wrote:
> > On Tue, Oct 20, 2026 at 11:36:20AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2026 at 03:13:19PM +0100, Yeoreum Yun wrote:
> > > > > I wouldn't over complicated it. We already have smccc bus to do this,
> > > > > we don't need layered stacks of busses here. Just change smccc bus to
> > > > > be able to break up the multi-function SMC into several devices.
> > > > 
> > > > I think my explaination was poor. Apologise...
> > > > I'm not saying another bus making but just wrapper of smccc-bus APIs
> > > > for firme specific and definietly, this would separate the
> > > > multi-function SMC to defien each firme device (attestation and IDE).
> > > 
> > > I don't see that kind of complexity is necessary.. I think it is
> > > better to just have the root smcc bus spawn them 
> > > 
> > > > But, the *base* is common. and I couldn't find any proper location to
> > > > deploy *common* code unless making arm_firme.
> > > 
> > > What common code excatly?
> > > 
> > > There shouldn't be? Getting an attestation is entirely orthogonal to
> > > set link ide, for example?
> > > 
> > > If you can identify what you think would ever be common that might
> > > help clarifgy what to do..
> > 
> > I mean the BASE service of firme and typical example is shared buffer
> > allocation. I agree IDE and attestaion service are orthogonal. but
> > in case of base-service is not. it could be used for both service.
> 
> It doesn't look like it needs a "shared buffer", just allocate it
> right before invoking the SMC that needs the memory. Use a simple
> library function to help allocate it. No need for a struct device
> layer.

Retrieving a PAT requires a buffer shared between the worlds. Before
allocating that buffer, the driver needs to query its requirements
through the BASE service's feature-query calls.

Considering possible extensions to the BASE service, my preference
would be to expose these operations through firme_device rather than
standalone library functions. The intention is to keep access to the
BASE service within FIRME-specific drivers and provide a consistent
interface for those drivers.

With this approach, arm_firme would handle the low-level FIRME calls
and their associated helpers, while the attestation driver would use
the service operations exposed through firme_device. This would keep
the attestation-specific logic separate from the details of the FIRME
interface and changes to its implementation.

If we implments this with library, are you thinking that file should
be located at driver/firmware/arm_firme or other place? though we make it
with library, I still think it should be located at
driver/firmware/arm_firme or some place in arch/arm64, but as
perspective abstraction to mange firme helpers in one place,
I think this design seems good.

-- 
Sincerely,
Yeoreum Yun