Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030287AbbENTIr (ORCPT ); Thu, 14 May 2015 15:08:47 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:40247 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030258AbbENTIp (ORCPT ); Thu, 14 May 2015 15:08:45 -0400 Date: Thu, 14 May 2015 20:08:23 +0100 From: Mark Brown To: Scott Branden Cc: Jonathan Richardson , Dmitry Torokhov , Anatol Pomazau , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, bcm-kernel-feedback-list , devicetree@vger.kernel.org Message-ID: <20150514190823.GR2761@sirena.org.uk> References: <1431452293-16697-1-git-send-email-jonathar@broadcom.com> <1431452293-16697-3-git-send-email-jonathar@broadcom.com> <20150512191718.GW3066@sirena.org.uk> <5553E31A.8060309@broadcom.com> <5553E9FA.4070708@broadcom.com> <20150514103144.GO2761@sirena.org.uk> <5554E715.7070203@broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtBqmokgY1evbO3C" Content-Disposition: inline In-Reply-To: <5554E715.7070203@broadcom.com> X-Cookie: 13. ... r-q1 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: [PATCH 2/2] spi: bcm-mspi: Add support for Broadcom MSPI driver. 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: 2347 Lines: 54 --vtBqmokgY1evbO3C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 14, 2015 at 11:19:01AM -0700, Scott Branden wrote: > On 15-05-14 03:31 AM, Mark Brown wrote: > >Chip vendors often say this sort of thing and then get surprised by what > >their users choose to do, and even if it only ever gets used with flash > >all it would take is some new flash command which can use full duplex > >for something. Please write the code so it at least tries to handle > >full duplex operation, if you can't test it fully that's not the end of > >the world. It doesn't look like it should be particularly difficult. > Yes, there is always room for improvements in code. In this case - it > really is not worth our time to add code we can't test. We try to deliver > code that we can test and actually works. Yes, if anyone needs to use the While I try to not apply code that has obvious problems with silent data corruption in it which is what we have just now. > mspi for full duplex operation code can be added in the future - it is > software. This block has gone through many generations of our SoCs and has > only been used for this purpose - the bootROM boots from this SPI only. It > is dedicated for this purpose. All it takes is one hardware engineer who sees a SPI controller and a GPIO they can use for chip select; I wouldn't be so sure that nobody ever fixed this up locally (or happened to use a device that only needed single duplex). --vtBqmokgY1evbO3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVVPKmAAoJECTWi3JdVIfQcZIH/3Qt4z6w2+tZTbnG0h6yKDYW W4P4pKqRyLPVVm1mLEDIJ1inJQYem9uEeBLEBQASHYe+l1nHvGCKH552IIeYmFrW XymK9odV7t8FW3fjS3NSX0wrvv9aGdtkBZif1Kivz+9DY5aw9jifGnclwLfSzCy6 q5JCVPNB1CyKKNyKztraMtzvxDnNJWhqWUO9frssWfRvIBM7Z8v7FIg8IfZoHlWe dsD4AnWSg2JrfDdgWPZrLDMtTWmebtCiR3YHO0uBufIxvvYw9WhcI0sYcc5590g/ yqyZeOScc1roitgm5UtQQBd0owTrlM1ohi8s8mqybftpOGmZsaW/nc5VDRjWnj4= =2uLb -----END PGP SIGNATURE----- --vtBqmokgY1evbO3C-- -- 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/