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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Oct 20, 2026 at 04:18:45PM +0100, Yeoreum Yun wrote:
> 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.

So? Make the query, allocate the buffer, get the token, free
it. Simple, one driver, no convoluted flows. Use a little library
style call or inline to reduce duplication if eventually necessary.

> 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.

Try not to overdesign things. If we don't know we need it now based on
how the current spec works don't imagine something else.

ARM spec design is informed by Linux implemetnation. Having a sane
simple implemtnation in Linux will motivate future specs changes to
align better.

> 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.

Will has indicated a preference for driver/firwmare

Jason