Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3445003pxv; Sun, 4 Jul 2021 19:42:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4wGycSbYpnKiGgk6yrGwvF6xX3HKRpELGrUjbIxM98PrwzOwzK4PC/eG5Hgh7JASNbaCG X-Received: by 2002:a17:907:e8e:: with SMTP id ho14mr11308769ejc.104.1625452956002; Sun, 04 Jul 2021 19:42:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625452955; cv=none; d=google.com; s=arc-20160816; b=SLXoWcszgzCACkNrm0XpqrmSEhjgxFlfCgH/0x3ytES1KCS/wUKWnI2LPadKpRFXVR 9S9kYw2gdLFoWdAleGUVJH93zOPBTf2J3U9JWa41VTrfw0jwkEcKW32mcdgZe8M01rZM k3k42KAJtcMHRX1dHkUNi8jo5OZZHsvwGem4hSHRGPwQy112KKwfFcgncIGA8MA/qsWB z4t7eSPwihv9AXM3Vk4h1+PxMMP6IdOtiG/uqm/ln5vLugraTs3kBjk/4GbQxiHwVhnU uVlbVpSFEa3GRGNleOSznlR0ZwMjbEAPU+Bh1RM4gzULOXow8K6rN8qCr5oyF/Gla2pT eHcA== 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=5/pN4Ke3pX5vwwN2WlNO8yjdHUq5AXPfMRLrRETfPdM=; b=0TpumLfQmxyvyUkiYX+HGub/0LT120vb1uOao6/qjEhEnrSn078NqlDBd/fBPefwtj kq+9A71JsnvQ2kK0HUktsPn0wro9RJ9uo/uIRx2GtBrT1KwX2lidglCd3ZRL7YjxNXoq MwNkXY00s2/koNvUgvNEf7hOQoigswMJKpWBzVcBWRAEPHE8LdtJHSJ/ETU4/e/DR5q0 RBLKfhscmevoD98kQ+naIATpf9vkIcGBOjohpRYRsLfYgYjhocAO8t36MEy96KufduH8 RpwL4O/X/z0mX35N1h8XuhC7NiJY/MuJTKl9hph1A32vxZL2MdVGAJ4Ihg5K3PP91Lb8 weKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aKHomYdc; 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 bm20si10822757ejb.81.2021.07.04.19.42.13; Sun, 04 Jul 2021 19:42:35 -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=aKHomYdc; 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 S229715AbhGECni (ORCPT + 99 others); Sun, 4 Jul 2021 22:43:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229652AbhGECnh (ORCPT ); Sun, 4 Jul 2021 22:43:37 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F960C061574 for ; Sun, 4 Jul 2021 19:41:00 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id j199so15007306pfd.7 for ; Sun, 04 Jul 2021 19:41:00 -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=5/pN4Ke3pX5vwwN2WlNO8yjdHUq5AXPfMRLrRETfPdM=; b=aKHomYdcEPhBlAt9kkJ9qhJHj4PKhbT8TgIKZmAadkH7oOmMWT7cO8Nc2Dh6r+KABy 0RcgKCkPwd9PD3TXkF4zAa6KFS+yFhm5nSMnR89DRg9ljePoxjE+xGbwDXJOtD1+RDjs 68unMHyVBNWNz0Bu/GPPH479FKPHzgOvubvi3NE/0q6wpbhwbt8YDwJyn50nP+W68MVW FdyYPUiMSa96ouDxzhvHnCLNgjRlVmpskQhqkZMmNj/I2IAIK/h2sspGxK2anoPE3lii bCW8i0qRetCnlEHomG0zBkx3BJbYyo3nhULU8cGXU0fArL/+TyqX0mtApAuIFlWnXq/M 53Qg== 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=5/pN4Ke3pX5vwwN2WlNO8yjdHUq5AXPfMRLrRETfPdM=; b=i/1rDKt7FQU8e7qh1/kxrc2Zou7l4f4SiAp01Zn656zx5CN5b211YixsBq9KyzVHGY M6ptj7UsPGCZwws2exnrwqDTzGU7zomwSPDXsm4oBmrjLnRq8SzfZVvD586NWdFcOQDf PQ6gjvvlI9zOaMhobLbTI8D+bh26KWaz48ILiznzc0fe7IJfPxxu/rxTds3qs/6rbVwW YtD3/IDY3kO76vqnjZzxWwbxgWYteSZpZ6AEodOPiaagun4yVftDcpvZ3DnDgnSrMNeB FO1eZwnMCfGehbGXWCRmPR21rHSxhRAFkkXf9RuCkg1lKv5iomhkxLlsevrUhifgG+c4 ZI1w== X-Gm-Message-State: AOAM533CFnFoabquvV6R1jKHtSQB2NIUQDQ1QAZBs2+YjGrwEw+y9W9V x3t55OHIydhygWeMTwuKfm5SpQ== X-Received: by 2002:a65:68c1:: with SMTP id k1mr13154806pgt.335.1625452859542; Sun, 04 Jul 2021 19:40:59 -0700 (PDT) Received: from localhost ([106.201.108.2]) by smtp.gmail.com with ESMTPSA id d1sm10001808pfu.6.2021.07.04.19.40.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jul 2021 19:40:58 -0700 (PDT) Date: Mon, 5 Jul 2021 08:10:56 +0530 From: Viresh Kumar To: Jie Deng Cc: linux-i2c@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, wsa@kernel.org, wsa+renesas@sang-engineering.com, 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 v12] i2c: virtio: add a virtio i2c frontend driver Message-ID: <20210705024056.ndth2bwn2itii5g3@vireshk-i7> References: 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 think we missed the first deadline for 5.14-rc1 as Wolfram should be out of office now. Anyway lets make sure we fix all the pending bits before he is back and see if we can still pull it off by rc2. On 02-07-21, 16:46, Jie Deng wrote: > diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c > +static int virtio_i2c_send_reqs(struct virtqueue *vq, It would be better to rename this to virtio_i2c_prepare_reqs instead, as this doesn't send anything. > + struct virtio_i2c_req *reqs, > + struct i2c_msg *msgs, int nr) > +{ > + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr; > + int i, outcnt, incnt, err = 0; > + > + for (i = 0; i < nr; i++) { > + /* > + * Only 7-bit mode supported for this moment. For the address format, > + * Please check the Virtio I2C Specification. > + */ > + reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1); > + > + if (i != nr - 1) > + reqs[i].out_hdr.flags = cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT); > + > + outcnt = incnt = 0; > + sg_init_one(&out_hdr, &reqs[i].out_hdr, sizeof(reqs[i].out_hdr)); > + sgs[outcnt++] = &out_hdr; > + > + if (msgs[i].len) { > + reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1); > + if (!reqs[i].buf) > + break; > + > + sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len); > + > + if (msgs[i].flags & I2C_M_RD) > + sgs[outcnt + incnt++] = &msg_buf; > + else > + sgs[outcnt++] = &msg_buf; > + } > + > + sg_init_one(&in_hdr, &reqs[i].in_hdr, sizeof(reqs[i].in_hdr)); > + sgs[outcnt + incnt++] = &in_hdr; > + > + err = virtqueue_add_sgs(vq, sgs, outcnt, incnt, &reqs[i], GFP_KERNEL); > + if (err < 0) { > + i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], false); > + break; > + } > + } > + > + return i; > +} The right way of doing this is is making this function return - Error on failure and 0 on success. There is no point returning number of successful additions here. Moreover, on failures this needs to clean up (free the dmabufs) itself, just like you did i2c_put_dma_safe_msg_buf() at the end. The caller shouldn't be required to handle the error cases by freeing up resources. > +static int virtio_i2c_complete_reqs(struct virtqueue *vq, > + struct virtio_i2c_req *reqs, > + struct i2c_msg *msgs, int nr, > + bool fail) > +{ > + struct virtio_i2c_req *req; > + bool failed = fail; > + unsigned int len; > + int i, j = 0; > + > + for (i = 0; i < nr; i++) { > + /* Detach the ith request from the vq */ > + req = virtqueue_get_buf(vq, &len); > + > + /* > + * Condition (req && req == &reqs[i]) should always meet since > + * we have total nr requests in the vq. > + */ > + if (!failed && (WARN_ON(!(req && req == &reqs[i])) || > + (req->in_hdr.status != VIRTIO_I2C_MSG_OK))) What about writing this as: if (!failed && (WARN_ON(req != &reqs[i]) || (req->in_hdr.status != VIRTIO_I2C_MSG_OK))) We don't need to check req here since if req is NULL, we will not do req->in_hdr at all. > + failed = true; > + > + i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], !failed); > + if (!failed) > + ++j; > + } > + > + return (fail ? -ETIMEDOUT : j); > +} > + -- viresh