Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4067671pxv; Mon, 28 Jun 2021 21:11:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSeDaTvinHiMQggQnky0fEO2Vd5s5U4Lh32o7kuNt2APu/e4SvemiBB5uOVX1vBMDyztRY X-Received: by 2002:a92:d58b:: with SMTP id a11mr1667001iln.305.1624939874106; Mon, 28 Jun 2021 21:11:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624939874; cv=none; d=google.com; s=arc-20160816; b=BJrwIbpo/ZALwItbazBvxhhQ2vd6mgA31uit9FX03k56fCjEmcDUcGdkqJXPT5gPYK ba2NffZQp8HWmZ7UwyeZvGJC+Tg/tDKhPG6KO/rWNiU8pcOwqOvwYpHN8Z0zBrpu3Qgo q6Sya+mke+KxproAuYITSMVYeAFCUXqFELMwS+Qmx7embsvpl5KR3ngoYTrE987HhTTy VB30IEn+vcdGUv56c1GDtCkMt55YVxy9B7L2VuYH8jqQV+dz1sMwgeI6MLhS4fjjZ1JE 6o2/8jDpEqdKAO8RIOEJehqPsUWKti7NHpA0ByPraliwgPvYnqSYYUThoD142fwmAAwL qOHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:to:from:date :dkim-signature; bh=HbCIMJbXR00eV4jPyvQKtQotReipOTL/gg7Z8DJ8llQ=; b=KDRC35wnMbftmmt9Xk5y0/4J7VBq7Q1hzB7ihHsL0UBGVbua1rqTMf6TY/e+6r3EY7 gUTWH3HiUj/PtWJeBKHg4XvrlGhaLk7MtwQgFUDpT0hWRDLOe8vyHk8/8J8pClpPoQVH 3UMlyNeC2CVavx2WYduWn6uuFQFLE9zjQQBCu9m11PidE2MzAzIgGGkgvmwFLeMWoc5i Gmum1JnjxLToUaTIwE8KuxFfyylClLCYwocc8IetNlnCAdGbaCiCOTR3FWuStIMmSqO/ XuzvnU4N48EONVZDQfyISOstKCgrKUtwZr6T2FdPPZSGaNdrcfAGEHBX+i8NIcPs4Ud8 eD+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="KevEF2v/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b3si18527679ion.58.2021.06.28.21.11.00; Mon, 28 Jun 2021 21:11:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="KevEF2v/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229634AbhF2EMv (ORCPT + 99 others); Tue, 29 Jun 2021 00:12:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229562AbhF2EMr (ORCPT ); Tue, 29 Jun 2021 00:12:47 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60A20C061760 for ; Mon, 28 Jun 2021 21:10:20 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id 80so1574582pgg.10 for ; Mon, 28 Jun 2021 21:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HbCIMJbXR00eV4jPyvQKtQotReipOTL/gg7Z8DJ8llQ=; b=KevEF2v/WbbhBrvu98MkRX2tgsJuIqO1/X0aBDBYmv8nqgbtIXE/gSpKRIi16iOJuf SOIak/iEwfohjS2dbJc932HfBoabsNbUOByEpKmvS4q3pznuX1/v43kcZ/dCWeccQH5l cXC+GHjt0NZflDe1/EU02kA/laewf6bVJF6ty7mwv6rTa5YRUKDDnv3qLCVUIg9Ysu3Y RD/xmgFsTwE+04voR7i+0aiZGct5b7daYDZC/x5qSVrsCOtplbOGBhLcNJcwdn04JHe6 xkjPCY04gld9AMc7SGJpO0iwZUpUl1pm+0ptTRGPldkg5cirW2lP+Gyhkrp0ZpUo+59q hPoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HbCIMJbXR00eV4jPyvQKtQotReipOTL/gg7Z8DJ8llQ=; b=KBy4xrMyDXdPimoOgZo1r1g4f5QAEWWdzLJjAVOGpaS01wGEZ/vYXmXuoh7sJuFb2K VmXoUHJO/261sUOZ33T6fwJwSxYKZ/qjte8sPPbRMifmcwJyTls1dWGeN+VbcYpyZMGI NJb3Wl7HRpddkDHGdRsRGjTWxdy+z3rjFtCRq97oo5GSRz1c0/Xs4zTsUcNy0rrVnatv bYouXJcs+oV1ioKxKDG4C0ZJf7e8JFGGduJr7R7cIhjTBI2z5PEgQ3amTqMFqocpIqvS y8q3ju8CN6e0qgUnqdMUhGyaHYldDY3CW1rZY8bDDX7GH1HEDj3jqDWaqmeEmMTjiyg3 Y0CQ== X-Gm-Message-State: AOAM533PH3sJacBRAbFQHsusUyDZMvjwPaLlAEQymMq1l3u0aES2j0FN 92HhsncF3EDYHcg4jxSbQM9wjw== X-Received: by 2002:a63:d811:: with SMTP id b17mr4522914pgh.286.1624939819758; Mon, 28 Jun 2021 21:10:19 -0700 (PDT) Received: from localhost ([136.185.134.182]) by smtp.gmail.com with ESMTPSA id y3sm16469487pga.72.2021.06.28.21.10.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Jun 2021 21:10:19 -0700 (PDT) Date: Tue, 29 Jun 2021 09:40:17 +0530 From: Viresh Kumar To: Wolfram Sang , Arnd Bergmann , Jie Deng , Linux I2C , virtualization@lists.linux-foundation.org, Linux Kernel Mailing List , "Michael S. Tsirkin" , Jason Wang , Andy Shevchenko , conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey Semin , Mike Rapoport , loic.poulain@linaro.org, Tali Perry , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Bjorn Andersson , yu1.wang@intel.com, shuo.a.liu@intel.com, Stefan Hajnoczi , Paolo Bonzini Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Message-ID: <20210629041017.dsvzldikvsaade37@vireshk-i7> References: <226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.1616493817.git.jie.deng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I will be replying here instead of replying to each and every msg :) On 28-06-21, 16:58, Wolfram Sang wrote: > > > You can fine Viresh's vhost-user implementation at > > https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.org/t/#m3b5044bad9769b170f505e63bd081eb27cef8db2 > > It looks OK so far; yet, it is not complete. But it might be bearable > in the end. While we are at it, this has been replaced by a Rust counterpart [1] (as that makes it hypervisor agnostic, which is the goal of my work here) and I need someone with I2C knowledge to help review it. It should be okay even if you don't understand Rust a lot, just review this file[2] which is where most of i2c specific stuff lies. > > As you say, it does get a bit clumsy, but I think there is also a good argument > > to be made that the clumsiness is based on the host Linux user interface > > more than the on the requirements of the physical interface, > > and that should not have to be reflected in the virtio specification. > > Makes sense to me. > > > Right, this one has come up before as well: the preliminary result > > was to assume that this probably won't be needed, but would be easy > > enough to add later if necessary. > > If adding support incrementally works for such an interface, this makes > sense as well. Yes, we don't support few of SMBUS transaction (the block ones) as you specified. > So, where are we? The virtio specification is already merged and here is the latest version [3]. > As I understand, this v10 does not support I2C transactions (or > I2C_RDWR as you said). I am not sure why you say I2C_RDWR isn't supported. The spec and Linux driver (+ my Rust/qemu backend), they all support I2C_RDWR as well as SMBUS. To clarify on an earlier point, every virtio transfer may contain one or more struct i2c_msg instances, all processed together (as expected). If you see virtio_i2c_send_reqs() in this patch, you will see that it converts a stream of i2c_req messages to their virtio counterparts and send them together, consider it a single transaction. > But you want to support all clients. So, this doesn't match, or? -- viresh [1] https://github.com/rust-vmm/vhost-device/pull/1 [2] https://github.com/rust-vmm/vhost-device/blob/5aa22c92faac84ab07b6b15a214513556e8b1d01/src/i2c/src/i2c.rs [3] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex