> On Jan 6, 2021, at 7:27 AM, Wolfram Sang <wsa@xxxxxxxxxx> wrote: > > On Wed, Jul 29, 2020 at 08:36:58PM +0000, daniel.stodden@xxxxxxxxx wrote: >> From: Daniel Stodden <dns@xxxxxxxxxx> >> I'm starting to lean toward silent truncate, return 0. >> Most permissive. > > I am sorry, this has been a while... :( Don’t be, I’m sorry. This came out of a SONiC-related project at work. Work got fixed and moved on. I was originally going to keep this an upstream project after hours, then fell off the rails. As for v2 — I still believe the direction is good. The main issue I had was that I lacked insight into one or more popular-enough commodity bus drivers (amd? nvidia? intel?), for further verification, as opposed to our proprietary accels around here. That 1->2 succession you outline below, starting with kernel and kernel-clients, sounds a lot like what I was missing. Daneil > But now I reserved some time and I am eager to get some SMBus3 blocklen > support into 5.12. My suggested roadmap looks like this: > > > 1) enable 256 block length in the kernel > > I will right now start to work on this. Add support to the I2C core and > audit the existing drivers because quite some get block length or > RECV_LEN wrong. This ensures we have working platforms for testing and > in-kernel users (TPM) can benefit already. I'd like to have that in 5.12 > upstream. > > 2) expose this to userspace > > Once I send out my first RFC-patches, we can build on top of those by > adding userspace support preserving backwards compatibility. If we have > this ready for 5.12, awesome! If not, we can still modify the kernel > interface to fit the needs. 5.13 would be great to have, I think. > > > I hope you guys are still with me. Especially for the userspace > backwards compatibility, I'd much appreciate if Daniel and Jean could > spend some time/thoughts on it. And everyone else interested, too, of > course. The more eyes the better. > > Thanks everyone, happy hacking and a healthy 2021 for you all! > > Wolfram
