Ballot Details: Resolve Issue #88: Add virtio-i2c device specification (CLOSED)

Ballot Question Should the TC accept changes listed in the description to resolve issue 88, for inclusion in specification version(s) "virtio-v1.2-cs01", and future versions of the specification?
Ballot Description Please vote Yes if you agree with all of the following.
If you disagree, please vote No.
If you don't have an opinion, please vote Abstain.

I move that:
The TC agrees to resolve the following specification issue:
Issue #88: Add virtio-i2c device specification
--------------------------------------
The specification: ([v1](https://lists.oasis-open.org/archives/virtio-comment/202009/msg00021.html), [v2](https://lists.oasis-open.org/archives/virtio-comment/202010/msg00005.html), [v3](https://lists.oasis-open.org/archives/virtio-comment/202010/msg00011.html), [v4](https://lists.oasis-open.org/archives/virtio-comment/202011/msg00005.html), [v5](https://lists.oasis-open.org/archives/virtio-comment/202011/msg00042.html)).

The upstream code patch is under review ([v1](https://www.spinics.net/lists/linux-i2c/msg47661.html), [v2](https://www.spinics.net/lists/linux-i2c/msg48032.html), [v3](https://lists.linuxfoundation.org/pipermail/virtualization/2020-September/049929.html), [v4](https://www.spinics.net/lists/linux-i2c/msg48703.html)) .
--------------------------------------

The TC accepts the following proposed changes to the specification:
--------------------------------------
https://lists.oasis-open.org/archives/virtio-comment/202011/msg00042.html
--------------------------------------

The TC agrees to include the above change(s) in specification version(s) "virtio-v1.2-cs01", and future versions of the
specification.

--------------------------------------

Reminder: A Voting Member must be active in a TC to maintain voting rights. As
the Virtio TC has adopted a standing rule to conduct business only by
electronic ballot, without Meetings, a Voting Member who fails to cast a ballot
in two consecutive Work Product Ballots loses his or her voting rights at the
close of the second ballot missed.

--------------------------------------
Ballot Options
VOTING CLOSED: Tuesday, 22 December 2020 @ 12:30 pm EST
Yes 2 25
No 6 75
Abstain 0
Open Date Tuesday, 15 December 2020 @ 12:30 pm EST
Close Date Tuesday, 22 December 2020 @ 12:30 pm EST
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 8
Eligible members who have voted 8 of 8 100%
Eligible members who have not voted 0 of 8 0%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 2 25%
No 6 75%
Abstain 0

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Carabas, Mihai Oracle Yes 2020-12-15 22:30:00
* Granata, Enrico Google Inc. Yes 2020-12-15 21:54:00
* Hajnoczi, Stefan Red Hat No 2020-12-16 15:53:00 1
* Huck, Cornelia Red Hat No 2020-12-16 17:41:00 1
* Kiszka, Jan Siemens AG No 2020-12-20 22:26:00
* Moell, Matti OpenSynergy GmbH No 2020-12-17 20:04:00 1
* Pasic, Halil IBM No 2020-12-19 00:11:00
* Tsirkin, Michael S. Red Hat No 2020-12-16 19:56:00 1

Voter Comments

Submitter Vote Comment
Moell, Matti
OpenSynergy GmbH
No I agree with Stefan, from the current version it is it's not sufficiently obvious how to interpret the fields in struct virtio_i2c_req
Huck, Cornelia
Red Hat
No I have several editorial comments, which I posted on the mailing list, which should be resolved prior to merging the proposed change.
Hajnoczi, Stefan
Red Hat
No The struct virtio_i2c_req memory layout is unclear to me. I posted a question (and others) on the mailing list.
Tsirkin, Michael S.
Red Hat
No I feel we are better off using length field
from the buffer. length within request just
adds corner cases.