Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

[Lina Iyer <lina.iyer@linaro.org>]

On Sat, Jul 18 2015 at 05:31 -0600, Ohad Ben-Cohen wrote:
>Hi Lina,
>
>On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> You are right, RAW capability is not lock specific. But we dont want to
>> impose this on every lock in the bank either.
>
>I'm not sure I'm following your concern here: drivers still need to
>explicitly indicate RAW in order for this to kick in, so this lenient
>approach is not being imposed on them.
>
Correct.

>Your original patch allowed every driver on all platforms to disable
>the sw spinlock mechanism. What I'm merely suggesting is that the
>underlying platform-specific driver should first allow this before it
>is being used, as some vendors prohibit this completely.
>
Agreed. Thats why the platform driver specifies the capability in hwcaps
flag.

>Let's not make this more complicated than needed, so please add the
>hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>could always change this later if it proves to be insufficient.
>
But this could yield wrong locking scenarios. If banks are allowed RAW
capability and is not enforced on a per-lock basis, a driver may lock
using non-raw lock using the _raw API, while another driver may
'acquire' the lock (since the value written to the lock would be the
same as raw api would). That is why you should have the capability on
hwspinlock and not on hwspinlock_device. Locks that are defined are RAW
capable should be used as RAW only.

QCOM platform hwlock #7 is unique that different CPUs trying to acquire
the lock would write different values and hence would be fine. But, the
same is not true for other locks in the bank.

Please let me know if this is not clear.

Thanks,
Lina