From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [RFC PATCH 1/6] spi: Extend the core to ease integration of SPI memory controllers Date: Mon, 12 Feb 2018 13:28:34 +0100 Message-ID: <20180212132834.10781446@bbrezillon> References: <20180205232120.5851-1-boris.brezillon@bootlin.com> <20180205232120.5851-2-boris.brezillon@bootlin.com> <40a44152-e62c-d57e-7646-7699301c29cc@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , , Mark Brown , , Peter Pan , Frieder Schrempf , Yogesh Gaur , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Kamal Dasu To: Vignesh R Return-path: In-Reply-To: <40a44152-e62c-d57e-7646-7699301c29cc-l0cyMroinI0@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On Mon, 12 Feb 2018 17:20:46 +0530 Vignesh R wrote: > Hi, > > On Tuesday 06 February 2018 04:51 AM, Boris Brezillon wrote: > > From: Boris Brezillon > > > > Some controllers are exposing high-level interfaces to access various > > kind of SPI memories. Unfortunately they do not fit in the current > > spi_controller model and usually have drivers placed in > > drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI > > memories in general. > > > > This is an attempt at defining a SPI memory interface which works for > > all kinds of SPI memories (NORs, NANDs, SRAMs). > > Wouldn't it be better if spi_mem* implementations were in separate file? > drivers/spi/spi.c is 3.5K+ lines and is bit difficult to follow. No strong opinion about where the spi_mem code should lie, so if Mark agrees I can move it to a different file and possibly make it optional with a Kconfig option. -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html