Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751527AbbG1Vv1 (ORCPT ); Tue, 28 Jul 2015 17:51:27 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:33518 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750854AbbG1Vv0 (ORCPT ); Tue, 28 Jul 2015 17:51:26 -0400 Date: Tue, 28 Jul 2015 15:51:22 -0600 From: Lina Iyer To: Ohad Ben-Cohen Cc: Bjorn Andersson , Jeffrey Hugo , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device Message-ID: <20150728215122.GE51847@linaro.org> References: <1433867020-7746-1-git-send-email-lina.iyer@linaro.org> <20150627030514.GA893@linaro.org> <20150702203028.GA4711@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1962 Lines: 46 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/