From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162221AbdD0Gnl (ORCPT ); Thu, 27 Apr 2017 02:43:41 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:36310 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162198AbdD0Gnc (ORCPT ); Thu, 27 Apr 2017 02:43:32 -0400 Message-ID: <59019306.2050309@mentor.com> Date: Wed, 26 Apr 2017 23:43:18 -0700 From: Jiada Wang User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120411 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mark Brown CC: Geert Uytterhoeven , Rob Herring , Mark Rutland , Shawn Guo , Sascha Hauer , Fabio Estevam , linux-spi , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH RFC 0/5] *** SPI Slave mode support *** References: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com> <20170413125929.dygodgj6c35ydh5p@sirena.org.uk> <58F06092.9080409@mentor.com> <20170425103113.lxpwoq6sbxvg3ihl@sirena.org.uk> In-Reply-To: <20170425103113.lxpwoq6sbxvg3ihl@sirena.org.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SVR-ORW-MBX-07.mgc.mentorg.com (147.34.90.207) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Geert and Mark On 04/25/2017 03:31 AM, Mark Brown wrote: > On Mon, Apr 24, 2017 at 12:55:21PM +0200, Geert Uytterhoeven wrote: >> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang wrote: >>> Our use case is to use spidev as an interface to communicate with external >>> SPI master devices. >>> meanwhile the SPI bus controller can also act as master device to send data >>> to other >>> SPI slave devices on the board. >> That sounds a bit hackish to me. SPI was never meant to be a multi-master bus. >> While it can be done, you will need external synchronization (signals) to >> avoid conflicts between the SPI masters. >>> I found in your implementation, SPI bus controller is limited to either work >>> in master mode or >>> slave mode, is there any reasoning to not configure SPI mode based on SPI >>> devices use case? >> If you really need both master and slave support, you can use 2 subnodes >> in DT, the first representing the master, the second the slave. >> Mark, what's your opinion about this? > That sounds like a mess... we *could* put the slave flag on the device > rather than the controller I guess but there's also going to need to be > something representing whatever avoids collisions on the bus somewhere. The reason I gave the example use case is want to point out that with Geert's patch set, a SPI device (with only one controller) can no longer act as master and slave at the same time. because IMO as a SPI core function, it needs to cover all the use cases, and to be as generic as possible. BUT if you think the use case don't need to be supported from SPI core, then I don't have objection either, I will only submit imx SPI slave support patch, after your SPI slave support patch set been applied Thanks, Jiada