From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Bostic Subject: Re: [PATCH v6 19/23] drivers/fsi: Add GPIO based FSI master Date: Thu, 11 May 2017 11:14:13 -0500 Message-ID: References: <20170410194706.64280-1-cbostic@linux.vnet.ibm.com> <20170410194706.64280-20-cbostic@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jeremy Kerr , Joel Stanley Cc: Rob Herring , Mark Rutland , Russell King , rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Greg KH , devicetree , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Linux Kernel Mailing List , Andrew Jeffery , Alistair Popple , Benjamin Herrenschmidt , "Edward A . James" List-Id: devicetree@vger.kernel.org On 5/10/17 8:58 PM, Jeremy Kerr wrote: > 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. Hi Jeremy, Understand now -will make the change. Thanks -Chris > Cheers, > > > Jeremy > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html