Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755289AbbHFJCi (ORCPT ); Thu, 6 Aug 2015 05:02:38 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:58120 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754526AbbHFJCe (ORCPT ); Thu, 6 Aug 2015 05:02:34 -0400 Date: Thu, 6 Aug 2015 10:02:02 +0100 From: Mark Brown To: Michal Suchanek Cc: "R, Vignesh" , devicetree , Brian Norris , Russell King , Tony Lindgren , Linux Kernel Mailing List , linux-spi , Huang Shijie , MTD Maling List , linux-omap@vger.kernel.org, David Woodhouse , "linux-arm-kernel@lists.infradead.org" Message-ID: <20150806090202.GO20873@sirena.org.uk> References: <1438072876-16338-1-git-send-email-vigneshr@ti.com> <1438072876-16338-2-git-send-email-vigneshr@ti.com> <20150731181745.GM20873@sirena.org.uk> <55BEF4AF.5090704@ti.com> <20150804155148.GR20873@sirena.org.uk> <55C0FD98.1090107@ti.com> <20150805115013.GJ20873@sirena.org.uk> <20150805124412.GN20873@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kVEG7nX9o2Fku/dg" Content-Disposition: inline In-Reply-To: X-Cookie: Please take note: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2769 Lines: 64 --kVEG7nX9o2Fku/dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote: > On 5 August 2015 at 14:44, Mark Brown wrote: > > On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote: > >> I don't think sending 03 or other random byte as the first byte of a > >> SPI transfer can be used as reliable detection that we are talking to > >> a SPI flash memory. > > Why care - if something is physically in the same format as a flash read > > command how would a device be able to tell that it wasn't actually a > > flash read command? The signals sent on the bus are going to be > > identical anyway. > Not only must the command be the same but also the response must be tha same. What difference would that make? The caller is sending a single SPI operation and this is a user visible thing... > The flash chip responds by sending arbitrary amount of data. Given > that transfer_one gets only the part that sends the read command and > the part to do the actual read may or may not follow this is getting a > bit hairy. Add in dummy bytes due to fast-read lag and page write > wrap-around and you get something that you definitely do not want > unless you are really sure that there is a flash memory on the other > end of the wire. So if you're doing this you may have a good reason to implement transfer_one_message() instead. Or perhaps implement it in the core and provide operations to do the map and unmap. And of course if this sort of requirement exists that's an obvious thing that must be documented in the interfaces but isn't. We need a lot more thought about the interface here, the lack of any explanation of what the interface is supposed to be and the fact that all questions about it are being answered in terms of describing the specific system are both a bit worrying. --kVEG7nX9o2Fku/dg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVwyKGAAoJECTWi3JdVIfQiYUH/0VIEkVZqyLsAeTxJFMAWxLp c7/RgUO0oBGWWp8OJrAT+IRDVgEJ7Nu5nSNtKch8jwSwtsIi1QeGYIcFUFsbEA8V fzGkMtp2/hnABtD2qciCc2r5AkJdB1rcbrFMqyVes8dbW3Otq9z9fu8K12x59FJr 2y2X6o5pqdrQPL6vH0GmUodWs28Rc0t5qsWbiXPm08k5TF27hEOF2O/0EKBNsDjS JIiVrqdybHfKjEF8nZCadt/MUlClpG3j/PCZlu9XFs1yKMFALIbbwfgQ1kF8N/Sh XVVhR02v16wmIecRjiPt7S23RhPspqkRiX6KtEJMNug0Rhs3w+5+T2c+tvQL1IE= =S1cX -----END PGP SIGNATURE----- --kVEG7nX9o2Fku/dg-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/