Messages in this thread | | | From | Enric Balletbo Serra <> | Date | Mon, 27 Feb 2017 22:30:32 +0100 | Subject | Re: [tpmdd-devel] [PATCH 1/2] tpm: Apply an adapterlimit for retransmission. |
| |
2017-02-27 20:12 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>: > 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. >
Sounds a good solution for me, I'll test and send a new version of the patches.
> BTW I noted that the original patch checks for -EINVAL. The core returns > -EOPNOTSUPP, though. So, a) the patch needs to be adapted
Yes I already detected this, In this series I forget to fixup the patch that fixed this when I did the git rebase. It's is fixed in the second version.
> and b) it > looks the i2c host driver returning -EINVAL could be converted to use > the quirk infrastructure? Which driver is it? > > Regards, > > Wolfram >
Regards, Enric
| |