From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754787AbdEKB6W (ORCPT <rfc822;w@1wt.eu>);
        Wed, 10 May 2017 21:58:22 -0400
Received: from ozlabs.org ([103.22.144.67]:41237 "EHLO ozlabs.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753492AbdEKB6V (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 10 May 2017 21:58:21 -0400
Subject: Re: [PATCH v6 19/23] drivers/fsi: Add GPIO based FSI master
To: Christopher Bostic <cbostic@linux.vnet.ibm.com>,
        Joel Stanley <joel@jms.id.au>
References: <20170410194706.64280-1-cbostic@linux.vnet.ibm.com>
 <20170410194706.64280-20-cbostic@linux.vnet.ibm.com>
 <CACPK8Xf1Y31+HBHb0ErpnZ4xVM+bzfHV-khj-kz8Unk1cTx6gw@mail.gmail.com>
 <c05599db-7767-e712-7199-7d5a4ac6486f@linux.vnet.ibm.com>
Cc: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>, rostedt@goodmis.org,
        mingo@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
        devicetree <devicetree@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Jeffery <andrew@aj.id.au>,
        Alistair Popple <alistair@popple.id.au>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        "Edward A . James" <eajames@us.ibm.com>
From: Jeremy Kerr <jk@ozlabs.org>
Message-ID: <a079022b-8434-a204-c9b4-696a0580fc8c@ozlabs.org>
Date: Thu, 11 May 2017 09:58:16 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <c05599db-7767-e712-7199-7d5a4ac6486f@linux.vnet.ibm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Chris,

> I don't think we'd want this per master.   The lock is for the 'top'
> master issuing commands.  Only the top master can initiate any
> transactions on the bus to any devices connected downstream. Downstream
> masters such as hub masters, etc... cannot initiate a command.

I think what Joel meant there was that we have it per *GPIO* master; if
there are two GPIO masters on a system, there's no need to provide
mutual exclusion to each (separate) set of GPIOs.

To implement this, we'd just move the lock into struct fsi_master_gpio.

Cheers,


Jeremy