Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5630879pxb; Mon, 28 Mar 2022 15:13:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyE81YjgRDqJdYIpWk5H+kD/Fdb28ZFqS+fK1G1bFun4Cw8zFuigKr9n/VO3ZYU9hzED1E4 X-Received: by 2002:a9d:66cd:0:b0:5b2:3cf2:2e21 with SMTP id t13-20020a9d66cd000000b005b23cf22e21mr10725374otm.5.1648505594337; Mon, 28 Mar 2022 15:13:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648505594; cv=none; d=google.com; s=arc-20160816; b=uSD9Z/YP8w+1sRmbBgnFIyhlLGgUGIFitC3q8f5kyulP5SaTxqLHlNPWipZmSNjKTx /bk4bP3GQkmlNV/Nu81ahA0asUeGXmaFd5W2G/Q455b5uterpGSM7+BE/VMS/ni87MpY hybrD+7HJoxSF6Wm834EvSuYH5sjyOwTCFq4ocFbiBRcYkRBClOmX7BRG77s63EfCsO6 b3dqgPheBhAWi4onMrRYAkuRiEGrXvzc/D+NEbP28Qmv/E6NC1iMISlqGOeD6LTZmIwE wjvocVJ35NdfAODGmVeBdXCLFvyd4qTeOYBS4Rkcarss7ZSV23IZsdAwi+xRd4K2L0Y9 1t5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xw6/eHXGYfyQo41MlHn2HdfwjJIHINXKEO94qSppq28=; b=ysEdfdCSAK4iTl1MKExBZmcBdm6XtRRM074/iZwVMTXNpYFqBbWSh4xz15JrpNk7du y+P8EXksf7IqLutnWzPkSGTUDIltksdzYeBI2AOIAmuoAHoESzRwoCQEFir01krobho1 PsreQHSsKtKMNT6ysjweVFslFP4rJqHECFSbqD4yQP/tTrgRR8fFwbo0ugyDGDNM7CX4 skhLY6Jd0gxwZ1DpL9yHi96MQumveqFc73hl7WWwq+psY/xbjJvd/LhyCusVgtYv8gxL 0e85axPBV62w7NwKNMXLkEfh/99tPYJlFg6eNpTQWyvaqBUT5Y4ndYo/rRnhLk4/aEHx 7Y6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=b9iImZGK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id s17-20020a05683004d100b005cb2fc137dcsi11682940otd.88.2022.03.28.15.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 15:13:14 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=b9iImZGK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 724BF16F059; Mon, 28 Mar 2022 14:32:45 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345246AbiC1Ulz (ORCPT + 99 others); Mon, 28 Mar 2022 16:41:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345349AbiC1Uk4 (ORCPT ); Mon, 28 Mar 2022 16:40:56 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63E47644C4; Mon, 28 Mar 2022 13:39:15 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id z92so18314778ede.13; Mon, 28 Mar 2022 13:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xw6/eHXGYfyQo41MlHn2HdfwjJIHINXKEO94qSppq28=; b=b9iImZGKfs3WXC8l0oFuFZaIT4EL8lWv990T7tzJDZ/JCoZfmiHuaQdc0wBbjADKgP pz9RoVFnLZtDqu7juxQR8eaS+NrrHwSFtVfQnijQAPH7NQqVwEKLMFwF6KCJnha01cku ZjxUGFM7SRxzSdQ05IFVG9EOK7WDaJ/nAVrd++ogw+D7GI52yQ4rkQ7SdzBX+DjMEH+o A1nKxj05unPlW0bLqxImCIf4qHc+PnsNdSxmO/Vak6uZtNRINsHJxAVyoY8TDxEFTy/w NGcv1jpMb8yBJGbzyXpIApg/IrNqwllJ310kyJZd3kogLQT8ziLRofCJhNUjSmwSm2Jk pdBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xw6/eHXGYfyQo41MlHn2HdfwjJIHINXKEO94qSppq28=; b=3usLX8XxP8xdqZ5gORVT2mdi/ItXvXnu6vIMbKuaaTIfOUr1zEfrGH59NKaZqs0zYe IiHFD+OTANmleKhohbZcPx3GyGzrTjR4qpTkMqms0ADP1q1QbYbhtrkpdAv6UsZXVZz7 ncoPHZAaIYW0ynwcYgl+bAQzE95W4P/Mh08SkAMIoEIMzPrj6hJzjXcsEs8Mrx8Tzup1 e/jsGSGVfYIHyrOLvVTy4igNdxE7/t509D4YYFQKlhEc57takHLBJKGbX2xeP5J6CDk/ gNTzeZS6Lu1rWJZgMLrDltyGLIYtHiwLs059a8LYtYGSPvMhFtSmxSL500ihjG6QLUm4 +qhQ== X-Gm-Message-State: AOAM530Oss3uW0mQrhg7TAQwiJoeXLvaNjrqb6nolpEj63Ik0/SMeGvu mB3D9rdGOXmVqbZRWecbbbnZChTII/vTJGwNUpE= X-Received: by 2002:a05:6402:27d1:b0:419:1b02:4a04 with SMTP id c17-20020a05640227d100b004191b024a04mr18437384ede.218.1648499953845; Mon, 28 Mar 2022 13:39:13 -0700 (PDT) MIME-Version: 1.0 References: <20220207125933.81634-1-paul@crapouillou.net> <20220207125933.81634-3-paul@crapouillou.net> In-Reply-To: <20220207125933.81634-3-paul@crapouillou.net> From: Andy Shevchenko Date: Mon, 28 Mar 2022 23:38:38 +0300 Message-ID: Subject: Re: [PATCH v2 02/12] iio: buffer-dma: Enable buffer write support To: Paul Cercueil Cc: Jonathan Cameron , Michael Hennerich , Lars-Peter Clausen , =?UTF-8?Q?Christian_K=C3=B6nig?= , Sumit Semwal , Jonathan Corbet , Alexandru Ardelean , dri-devel , linaro-mm-sig@lists.linaro.org, Linux Documentation List , Linux Kernel Mailing List , linux-iio Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 9, 2022 at 9:10 AM Paul Cercueil wrote: > > Adding write support to the buffer-dma code is easy - the write() > function basically needs to do the exact same thing as the read() > function: dequeue a block, read or write the data, enqueue the block > when entirely processed. > > Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write() > now both call a function iio_buffer_dma_io(), which will perform this > task. > > The .space_available() callback can return the exact same value as the > .data_available() callback for input buffers, since in both cases we > count the exact same thing (the number of bytes in each available > block). > > Note that we preemptively reset block->bytes_used to the buffer's size > in iio_dma_buffer_request_update(), as in the future the > iio_dma_buffer_enqueue() function won't reset it. ... > v2: - Fix block->state not being reset in > iio_dma_buffer_request_update() for output buffers. > - Only update block->bytes_used once and add a comment about why we > update it. > - Add a comment about why we're setting a different state for output > buffers in iio_dma_buffer_request_update() > - Remove useless cast to bool (!!) in iio_dma_buffer_io() Usual place for changelog is after the cutter '--- ' line below... > Signed-off-by: Paul Cercueil > Reviewed-by: Alexandru Ardelean > --- ...somewhere here. > drivers/iio/buffer/industrialio-buffer-dma.c | 88 ++++++++++++++++---- > include/linux/iio/buffer-dma.h | 7 ++ ... > +static int iio_dma_buffer_io(struct iio_buffer *buffer, > + size_t n, char __user *user_buffer, bool is_write) I believe there is a room for size_t n on the previous line. ... > + if (is_write) I would name it is_from_user. > + ret = copy_from_user(addr, user_buffer, n); > + else > + ret = copy_to_user(user_buffer, addr, n); ... > +int iio_dma_buffer_write(struct iio_buffer *buffer, size_t n, > + const char __user *user_buffer) > +{ > + return iio_dma_buffer_io(buffer, n, (__force char *)user_buffer, true); Why do you drop address space markers? > +} -- With Best Regards, Andy Shevchenko