From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Kerr Subject: Re: [PATCH v6 19/23] drivers/fsi: Add GPIO based FSI master Date: Thu, 11 May 2017 09:58:16 +0800 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 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christopher Bostic , 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 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 -- 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