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

[Srirangan Madhavan <smadhavan@nvidia.com>]

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