From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: RfC: Handle SPI controller limitations like maximum message length Date: Fri, 20 Nov 2015 19:21:57 +0000 Message-ID: <20151120192157.GF1929@sirena.org.uk> References: <564CEB61.2000601@gmail.com> <20151120000226.GP64635@google.com> <564EC4E0.90602@gmail.com> <20151120123540.GC1929@sirena.org.uk> <564F6D99.8090203@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4f28nU6agdXSinmL" Cc: Heiner Kallweit , Brian Norris , MTD Maling List , "linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Martin Sperl To: Michal Suchanek Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: --4f28nU6agdXSinmL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 20, 2015 at 08:05:48PM +0100, Michal Suchanek wrote: > I don't think ignoring errors in general is good idea. > If it's desirable that a partial transfer is reported as error then a > particular error value should be defined for this case and drivers > that can continue the transfer in a driver-specific way (such as > spi-nor) can check for this error and handle it appropriately and pass > through any other error. Fundamentally callers just shouldn't be trying to do excessively large transfers in the first place, this is why we want capability reporting. *Any* error code could indicate a truncation, we may have truncated due to some length limitation but it could also be that there was some hardware problem that occurred mid transfer or something similar. --4f28nU6agdXSinmL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWT3LVAAoJECTWi3JdVIfQm+kH/iCuYCtjXTEkZk8I5D5ZU9Yv Y24RO6PFYZHkRJoyv0rOb2jl+Hads2lX0xW7jcbO/peVyyxoPgG37OadKUnlTsE5 EyMYPzykLIg359rvrwt2hBBpq0iiawV2MIsuWZAJtFErEvOjb32rn/YNgm3Gzi4c 3KEYDnUd7Zw1yc/oWjK4AFU/PMSVxud/hWaDB3eEJK1Z2ZOQuXnIb6Zy1i8pmMA6 bmPYEZusUR5bMCJmpKCwmUgTzlXZFtadux3lboLciPi/OMpbQAJACRZR1kP0A5qH AWuuG5ZXv5vZ8QOAr296TurMCmba/THFLknqZUqWu4E0fvlY1rnQSiubyyHb+y4= =eG+H -----END PGP SIGNATURE----- --4f28nU6agdXSinmL-- -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mezzanine.sirena.org.uk ([2400:8900::f03c:91ff:fedb:4f4]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZzrGI-0002ra-4x for linux-mtd@lists.infradead.org; Fri, 20 Nov 2015 19:22:22 +0000 Date: Fri, 20 Nov 2015 19:21:57 +0000 From: Mark Brown To: Michal Suchanek Cc: Heiner Kallweit , Brian Norris , MTD Maling List , "linux-spi@vger.kernel.org" , Martin Sperl Message-ID: <20151120192157.GF1929@sirena.org.uk> References: <564CEB61.2000601@gmail.com> <20151120000226.GP64635@google.com> <564EC4E0.90602@gmail.com> <20151120123540.GC1929@sirena.org.uk> <564F6D99.8090203@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4f28nU6agdXSinmL" Content-Disposition: inline In-Reply-To: Subject: Re: RfC: Handle SPI controller limitations like maximum message length List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --4f28nU6agdXSinmL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 20, 2015 at 08:05:48PM +0100, Michal Suchanek wrote: > I don't think ignoring errors in general is good idea. > If it's desirable that a partial transfer is reported as error then a > particular error value should be defined for this case and drivers > that can continue the transfer in a driver-specific way (such as > spi-nor) can check for this error and handle it appropriately and pass > through any other error. Fundamentally callers just shouldn't be trying to do excessively large transfers in the first place, this is why we want capability reporting. *Any* error code could indicate a truncation, we may have truncated due to some length limitation but it could also be that there was some hardware problem that occurred mid transfer or something similar. --4f28nU6agdXSinmL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWT3LVAAoJECTWi3JdVIfQm+kH/iCuYCtjXTEkZk8I5D5ZU9Yv Y24RO6PFYZHkRJoyv0rOb2jl+Hads2lX0xW7jcbO/peVyyxoPgG37OadKUnlTsE5 EyMYPzykLIg359rvrwt2hBBpq0iiawV2MIsuWZAJtFErEvOjb32rn/YNgm3Gzi4c 3KEYDnUd7Zw1yc/oWjK4AFU/PMSVxud/hWaDB3eEJK1Z2ZOQuXnIb6Zy1i8pmMA6 bmPYEZusUR5bMCJmpKCwmUgTzlXZFtadux3lboLciPi/OMpbQAJACRZR1kP0A5qH AWuuG5ZXv5vZ8QOAr296TurMCmba/THFLknqZUqWu4E0fvlY1rnQSiubyyHb+y4= =eG+H -----END PGP SIGNATURE----- --4f28nU6agdXSinmL--