Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1303881pxv; Thu, 1 Jul 2021 23:57:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7Zkl7zmYeMKcxiZxclfvWFeZ1RgNS57pTUe8AA1UadSx/asAvcKxa6IraddfLcmA7FuPQ X-Received: by 2002:a5d:9648:: with SMTP id d8mr21952ios.171.1625209053022; Thu, 01 Jul 2021 23:57:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625209053; cv=none; d=google.com; s=arc-20160816; b=wjLwih1AUJlSAe0rgCqxxezMcvH/qB10XST5qqBs6gg8byVC5cLiAl98M4GuPFGXKq dgm5OBxf92FexhY/oGOxilFJ7DyuYVyvclW95cSdFfadaeob8P2araZElZRB5k/V0xl+ RhOmpAMM4ooS8DB0o7raW85/mt7mJ3GFVKJESZu9pjc7Y0MekF+4PwTrDvaLWznQDt/J wamia3vmqcjwW8pWKGV3eZ0Rc0G4qQsBZH7vrkY4IALJuXnyoipcH6LqZyDxhVUmJVNG 1APx4YjlARGcAb1fbzhx9XNkMtjDP9vUjj82+D09IyKPqGEN+7ORwzp+u3ynVOe/m/t4 VdFw== 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:cc:to:from:date :dkim-signature; bh=bRTZFZ1E3CpWrLbQ7HRC4Me3IA6jdcuP5hZkPy8aTqQ=; b=mxDtm4MwJcz8khc/zSdj8YfKmybe6Z2+3Km5WFZGlFaCZEJ+cd+nOmw0+p/Dxg62xw 83pd0F+cU00WbL3bUy38jb7cdDQptnvtu28EtPPe6A+QA5qJNKPJV8C/zYdg4FRMz8QX 4qESgrk6seKF+Ykbd+A5SPYN0IcTRXxbiAguuSHdN8aHOatF0Kk5/tdEM1rOcuyFRn1g +37oIwxWVmacqc3WqNJy0cnpIw48h0fKpkMtZN/FpxCfwZC6C014fdeR0kIjaCX2IQrL /z010fcVmg73OZ55qH92ObgnCfpJMFFzInyHVh0TjSNO9SKB5yANXXSYPc8QFGU8V+oF bESg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cPTSpOr4; 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 g25si2456014iox.51.2021.07.01.23.57.19; Thu, 01 Jul 2021 23:57:32 -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=cPTSpOr4; 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 S230048AbhGBG7A (ORCPT + 99 others); Fri, 2 Jul 2021 02:59:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230041AbhGBG7A (ORCPT ); Fri, 2 Jul 2021 02:59:00 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B04BEC061764 for ; Thu, 1 Jul 2021 23:56:28 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id g22so8668542pgl.7 for ; Thu, 01 Jul 2021 23:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bRTZFZ1E3CpWrLbQ7HRC4Me3IA6jdcuP5hZkPy8aTqQ=; b=cPTSpOr4Y/ib3p0oVnLcMOPoCVA4W1519zFDRhfxi/uCtnS57a1MfwBzYEH9JJnTXg 8MzSrGxsX9E/7tvsWnkkpL2FdMmKxWCRn05paSKE7R0C7X12dizUgxonJ/cZhu3p8Pi6 ZxOF5CxF+VsXgzt3zYkNvbGKfbfnvf0Xmgg6g83a/CUV3Kk2Sm8hBbuXWQOTJbQOpL4D 2u7ZKhxrMgTlFp9gvGFE7htnxEWSMikZM+7ae7FovIVVaSzPKEih1VWpYHaqqKB0z/7m elg+D+S/qK8GfNncidfw2annOuFP6gf7Gqdnruf5ENF55lVCzRCCOHr2pA4KZ1agDDMu HNWA== 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bRTZFZ1E3CpWrLbQ7HRC4Me3IA6jdcuP5hZkPy8aTqQ=; b=ZfzdnHC4yNGk9dFXR8Es7rh3dKYI0x3TIWmUGSDTMI4kVcCPdCsxv2w1fJ4DReGu/v 3FmDa0GzPw1qq7fYP4nv9x5lw092MhbBrjn0Aebjh4XV48Fqr2NRomgpH1EFZU6H1WyB uwCgMk5HyX9ScipdFl8iznEjDFt4X1SlXSXjfQ5lcBtGoTH/VdsUOe5RQyulfyv4PcCu KCZ/gzegWiP0N7JOsktUxwfKaR4ZyAltZ8+SoU6a5KUdq/dFTcGHADe2ZZy/54yrr4mz oOTXIwqx0z7XsGSPM+V65G4n6Ofhqw8pL4ATuY4a+W6tpeFa8fMGeAQwBOJwih4Pj4r8 udvw== X-Gm-Message-State: AOAM531JgfyBf1ELUitutzCBrbQxFiTlxJS3osYUoi82mA2McPV93AW6 eKG1f7udJ6OGPO4HtZTgmgtVyQ== X-Received: by 2002:a65:6544:: with SMTP id a4mr286407pgw.280.1625208988205; Thu, 01 Jul 2021 23:56:28 -0700 (PDT) Received: from localhost ([106.201.108.2]) by smtp.gmail.com with ESMTPSA id p29sm2206840pfq.55.2021.07.01.23.56.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jul 2021 23:56:27 -0700 (PDT) Date: Fri, 2 Jul 2021 12:26:25 +0530 From: Viresh Kumar To: Jie Deng Cc: Wolfram Sang , linux-i2c@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, mst@redhat.com, arnd@arndb.de, jasowang@redhat.com, andriy.shevchenko@linux.intel.com, yu1.wang@intel.com, shuo.a.liu@intel.com, conghui.chen@intel.com, stefanha@redhat.com Subject: Re: [PATCH v11] i2c: virtio: add a virtio i2c frontend driver Message-ID: <20210702065625.qielhnfyrlvrtrkk@vireshk-i7> References: <510c876952efa693339ab0d6cc78ba7be9ef6897.1625104206.git.jie.deng@intel.com> <20210701040436.p7kega6rzeqz5tlm@vireshk-i7> <20210702045512.u4dvbapoc5a2a4jb@vireshk-i7> <409b6cc3-3339-61b2-7f42-0c69b6486bb3@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409b6cc3-3339-61b2-7f42-0c69b6486bb3@intel.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02-07-21, 14:52, Jie Deng wrote: > This is not efficient. If adding the ith request to the queue fails, we can > still send > > the requests before it. Not really. Normally the requests which are sent together by clients, are linked together, like a state machine. So if the first one is sent, but not the second one, then there is not going to be any meaningful result of that. The i2c core doesn't club requests together from different clients in a single i2c_transfer() call. So you must assume i2c_transfer(), irrespective of the number of underlying messages in it, as atomic. If you fail, the client is going to retry everything again or assume it failed completely. > We don't need to know if it fails here (adding to > the queue) > > or there (later in the host). The "master_xfer" just need to return final > number of > > messages successfully processed. No, that isn't going to help and it is rather inefficient, trying to send transfer when we already know part of it failed. -- viresh