On 02/03/2026 20:12, Andrew Davis wrote:
> On 2/23/26 2:24 PM, Krzysztof Kozlowski wrote:
>> All the functions operating on the 'handle' pointer are claiming it is a
>> pointer to const thus they should not modify the handle.  In fact that's
>> a false statement, because first thing these functions do is drop the
>> cast to const with container_of:
>>
>>    struct ti_sci_info *info = handle_to_ti_sci_info(handle);
>>
>> And with such cast the handle is easily writable with simple:
>>
>>    info->handle.version.abi_major = 0;
>>
> 
> The const is for all the consumers drivers of the handle. Those
> consumers cannot do the above becouse both handle_to_ti_sci_info()
> and struct ti_sci_info itself are only defined inside ti_sci.c.
> 
>> The code is not correct logically, either, because functions like
>> ti_sci_get_handle() and ti_sci_put_handle() are meant to modify the
>> handle reference counting, thus they must modify the handle.
> 
> The reference counting is handled outside of the ti_sci_handle struct,
> the contents of the handle are never modified after it is created.
> 
> The const is only added by functions return a handle to consumers.
> We cannot return non-const to consumer drivers or then they would
> be able to modify the content without a compiler warning, which would
> be a real problem.

This is the same argument as making pointer to const the pointer freed
via kfree() (or free() in userspace). kfree() does not modify the
contents of the pointer, right? The same as getting putting handle does
not modify the handle...

The point is that storing the reference counter outside of handle does
not make the argument correct. Logically when you get a reference, you
increase the counter, so it is not a pointer to const. And the code
agrees, because you must drop the const.


> 
> Andrew
> 
>> Modification here happens anyway, even if the reference counting is
>> stored in the container which the handle is part of.
>>
>> The code does not have actual visible bug, but incorrect 'const'
>> annotations could lead to incorrect compiler decisions.
>>


Please kindly trim the replies from unnecessary context. It makes it
much easier to find new content.


Best regards,
Krzysztof

Reply via email to