Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755582AbaGCHAm (ORCPT ); Thu, 3 Jul 2014 03:00:42 -0400 Received: from mail-la0-f49.google.com ([209.85.215.49]:64783 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754368AbaGCHAk (ORCPT ); Thu, 3 Jul 2014 03:00:40 -0400 MIME-Version: 1.0 X-Originating-IP: [89.139.36.201] In-Reply-To: <53B47621.6090307@ti.com> References: <1398904476-26200-1-git-send-email-s-anna@ti.com> <1398904476-26200-4-git-send-email-s-anna@ti.com> <53B47621.6090307@ti.com> From: Ohad Ben-Cohen Date: Thu, 3 Jul 2014 10:00:18 +0300 Message-ID: Subject: Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks To: Suman Anna Cc: Mark Rutland , Kumar Gala , Tony Lindgren , Josh Cartwright , Bjorn Andersson , "linux-kernel@vger.kernel.org" , "linux-omap@vger.kernel.org" , "devicetree@vger.kernel.org" , linux-arm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna wrote: >> I'm not sure we need this patch. > > This patch is needed if we use the controller-phandle + args specifier > for requesting hwlocks by a client, as we need to translate > controller-phandle to the corresponding hwspinlock_device. > > Looks like we still don't have a closure on the semantics of how > clients have to request a lock in DT. You are suggesting something like > hwlocks = ; > > whereas this patch is built to support based on comments from > DT-maintainers, > hwlocks = , lock-specifier2>...; I'm actually ok with this suggestion and haven't suggested otherwise. All I propose is that we add the base_id property to the controller node (as you have done in the subsequent patches), and then drivers will be able to infer the global lock id from the DT data by adding the controller's base_id to the lock specifier. Controllers with non standard lock indexing may use an xlate() method if needed but frankly this is fictional right now. We can start without this, and add it later when needed, as this doesn't affect the DT data. With the global lock id in hand, drivers could simply use the existing hwspin_lock_request_specific API to obtain a specific lock, and then we don't need this patch. Thanks, Ohad. -- 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/