Re: [PATCH v7 07/10] tmp, tmp_tis: Implement usage counter for locality

[Lino Sanfilippo]

Hi Jarkko,

On 28.07.22 at 17:45, Lino Sanfilippo wrote:

>>>
>>> This means switching to a complete new locking scheme which affects many
>>> parts of the TIS core code. It is also not directly related to what this patch series
>>> is about, namely activating the interrupts for TPM TIS.
>>>
>>> I suggest to first finish polishing this series especially since there have
>>> only been minor issues in the last versions. Once the interrupts work we
>>> still can think of implementing another lock handling in a follow up series.
>>
>> So what if you would use kref instead here?
>>
>
> Sure, that should not be too difficult to do. I will implement this for the next version.
>
> Regards,
> Lino
>

First of all, sorry for this very late reply. Unfortunately in the last weeks I was
not able to work further on this series due to my private situation.
Nevertheless I tried to implement your suggestion (using krefs for the locality counting)
meanwhile. However krefs turned out to be a rather bad fit for this task.

The reason is that for the locality handling we have to perform a certain action (i.e.
writing to the access register) on two occasions:

1. When the locality is requested while no locality is active
2. When the locality has been released the number of times it has been requested before

Since a kref is designed to track the lifetime of an object which is freed as soon as the
kref counter hits 0, it starts with a counter of 1 when it is created, not with a counter 0
(as we would need it, since at the beginning nothing has claimed the locality yet).
Furthermore while kref provides a built-in mechanism to execute a function when the counter
hits 0 it does not provide anything similar for the case that the counter is increased the
first time (i.e when we want to claim the locality by writing to the access register).

So although certainly doable I do not see much gain from using krefs in this case. Again,
sorry for this late reply.

Regards,
Lino