From: Wolfram Sang <wsa@the-dreams.de>
To: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Peter Huewe <peterhuewe@gmx.de>,
Marcel Selhorst <tpmdd@selhorst.net>,
apronin@google.com, tpmdd-devel@lists.sourceforge.net,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission.
Date: Mon, 27 Feb 2017 20:12:45 +0100 [thread overview]
Message-ID: <20170227191245.ecord2i7o6jwec5k@ninjato> (raw)
In-Reply-To: <CAFqH_536FjjkWiUS_5PyDJHHgy6S8BvBzArAxSAg6H6oa214KA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
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 <wsa@the-dreams.de>, 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-02-27 19:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 14:44 Enric Balletbo i Serra
2017-02-21 14:45 ` [PATCH 2/2] tpm: Do not assume an i2c adapter preserves the msg len Enric Balletbo i Serra
2017-02-21 16:29 ` [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission Andrew Lunn
2017-02-22 11:16 ` Enric Balletbo i Serra
2017-02-22 14:01 ` Andrew Lunn
2017-02-27 18:48 ` Enric Balletbo Serra
2017-02-27 19:12 ` Wolfram Sang [this message]
2017-02-27 21:30 ` Enric Balletbo Serra
2017-03-02 13:15 ` Peter Huewe
2017-03-02 14:05 ` Wolfram Sang
2017-03-02 14:10 ` Wolfram Sang
2017-02-22 12:39 ` Peter Huewe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170227191245.ecord2i7o6jwec5k@ninjato \
--to=wsa@the-dreams.de \
--cc=andrew@lunn.ch \
--cc=apronin@google.com \
--cc=eballetbo@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=tpmdd-devel@lists.sourceforge.net \
--cc=tpmdd@selhorst.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®