From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751909AbdB0TNn (ORCPT ); Mon, 27 Feb 2017 14:13:43 -0500 Received: from sauhun.de ([89.238.76.85]:49757 "EHLO pokefinder.org" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751586AbdB0TNC (ORCPT ); Mon, 27 Feb 2017 14:13:02 -0500 Date: Mon, 27 Feb 2017 20:12:45 +0100 From: Wolfram Sang To: Enric Balletbo Serra Cc: Andrew Lunn , Enric Balletbo i Serra , Peter Huewe , Marcel Selhorst , apronin@google.com, tpmdd-devel@lists.sourceforge.net, linux-kernel Subject: Re: [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission. Message-ID: <20170227191245.ecord2i7o6jwec5k@ninjato> References: <20170221144500.502-1-enric.balletbo@collabora.com> <20170221162948.GD25818@lunn.ch> <20170222140134.GA23586@lunn.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pfm22rx7hy4aoghe" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161126 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --pfm22rx7hy4aoghe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > >> > Rather than trying small and smaller transfers, would it not be better > >> > to get the i2c core to expose the quirk info about transfer limits? > >> > > >> > >> Sounds a good idea to me, I guess the quirk info can be accessed with > >> > >> tpm_dev.client->adapter->quirks->max_read_len > >> > >> so I think we don't need to touch the i2c core. I'll propose a second version of the patch. > > > > Hi Enric > > > > You should probably ask Wolfram Sang , the i2c > > subsystem maintainer. He may prefer adding an API call. Thanks for pointing me to this thread. I understand it looks tempting to use the quirks struct directly, but I don't think this is the proper solution. Quirks are complex and and to determine which one finally applies, you need all the logic encoded in i2c_check_for_quirks(). Which already gets called on every transfer. So, my suggestion would be to simply fall back to a sane minimum when the maximum failed. 32 (I2C_SMBUS_BLOCK_MAX) should be a good choice. BTW I noted that the original patch checks for -EINVAL. The core returns -EOPNOTSUPP, though. So, a) the patch needs to be adapted and b) it looks the i2c host driver returning -EINVAL could be converted to use the quirk infrastructure? Which driver is it? Regards, Wolfram --pfm22rx7hy4aoghe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAli0eh4ACgkQFA3kzBSg KbawLA/+NaOT9wE9qrQ4JU6eIOs+P+i+sD7UC0Zy/OeAlzP2mWgSl8tNcUQMDMN3 8czgoisHsGFIcYXvgMO5rtryneXF6ftM3aoQML78tGjsIOE4T8XFC6Img05OIufG pkWB1WX/7hFYJRM8vKyR7DqPwCv9h9bK8LMlSLaGfpQh99i4UTdIVxbA5sZDwTYz PvJ0yd/38Kb5+5nZQdXcRTj5D0bu6Xpqa2k2mhbEdCEqr6rDgQCiWoMV2q1Emg0a nd5ftFkm86xjwIBoJcTKuZPLm3ZcH2Z4BAsNLM0+AVWnR7OR7+eSgxG7ATt8v0sa p/DxcIiwEMA6wxAyzW/Pos8RpMf3LFUGnkzlluHw+OydS2FvryT2+wQmkUYi5rJ3 rf/lgMNT86R1ECSjnWPCkRECIkUG2jYUy1H50RuIdqD0LboozXLeu3ZKtPpUiRNR r0FT6Z3MUI8FIoaDNaFPCj+CqyeI2b9eqLqI9jw7GlCQyEu245bmRkm2dOISXU0o iI3A3CgCDxSO4hh2l5DH+79cLKa1XWtW2hTSvsjNEKa/i1Inek791Ja0EAm8TTjF h9BD6movBs1NIUZ8q8fOWKR8k2rL4cieaAic0OEUmEg0UpCFA6v2pn/KpAQGVT9Y EiBWdWPl+IfzxcgjEy+zH//4M5CfbQizpKmYCTJDl6GX48v8GTw= =wqJf -----END PGP SIGNATURE----- --pfm22rx7hy4aoghe--