Re: [PATCH v4 2/2] cache: add SMCCC-backed cache invalidate provider

[Srirangan Madhavan]

On 10/15/26 3:03 AM, Andre Przywara wrote:
> > > > +static int smccc_cache_probe(struct arm_smccc_device *sdev)
> > > > +{
> > > > +    struct arm_smccc_res res = {};
> > > > +    struct smccc_cache *cache;
> > > > +    int ret;
> > > > +
> > > > +    arm_smccc_1_1_invoke(sdev->func_id, &res);
> > >
> > > I think you should provide the explicit function ID name here, and not
> > > rely on which function exactly is used to probe for the interface's
> > > existence.
> >
> > I thought that was the point of the matcher, that you could in theory
>
> But that probe() function here is not a "matcher" or a check function,
> that is done in the SMCCC bus generic code, using a function ID that has
> no side effects and does not return -1.
>
> The reason for this SMC call here is to learn the attributes, they are
> used below to fill the latency and rate_limit fields in the struct.
> So we should then make this explicit, I think, by using the
> ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES name.
> > assign the same probe handler to any function ID? For example if there's
> > some FW that implements this (or a compatible) function, but at a
> > different ID, you would only update the match table? At least that's how
> > most subsystems (I2C, PCI, USB) do it.
>
> Not sure I understand this, this is a driver specifically for the
> CLEANINV_MEM_REGION SMCCC interface, I don't see how you would reuse
> that, or plug any other interfaces to it.

Thanks. The SMCCC bus has already performed the device matching before 
probe(), and this invocation is specifically used to retrieve the cache 
maintenance attributes. I changed this in v5 to use the explicit 
function ID.

--
Regards,
Srirangan