Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1448696rwb; Fri, 19 Aug 2022 04:03:28 -0700 (PDT) X-Google-Smtp-Source: AA6agR5mAJ6zBBuEuv0nzCufY7MSdwmymRbW1dHp/8CwUa9PhiAnyaYZ0zNU51Afjrf2cHuThaup X-Received: by 2002:a17:907:6e12:b0:730:bc12:82e3 with SMTP id sd18-20020a1709076e1200b00730bc1282e3mr4732275ejc.36.1660907007750; Fri, 19 Aug 2022 04:03:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660907007; cv=none; d=google.com; s=arc-20160816; b=bM5cTLzD7Fmhu1doXt0JT1nB8pVpJqe5p9cf+SB6ZdPXIhGYN6zpmih5P+yDkwr+JL Ir4l8RkF43ltd1PcKp1Z1EN77fsnlD67Np/fl+odp8jdyJcxVmKYLD395sofV0zLN4cv tH2IS3+WVPR21jUWKUq2DZnrC5kn4yNjMlK1dmLlwDAY5OXEdX6NLiplF9NJ7gLFFu5d cj8+eQlyS9Q0YL+l/veWCpxSqJRkxxAKzyUgOK8GnZ18eXhDLulGiTT8T218vSBvqTdv FxO4IG8PSzfJC58baTz91g/zg87NjPYw2mFFomBYo96Y9DYsRJMIcZlLQXGkyZc5/LC+ wh4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:references :in-reply-to:subject:cc:to:from:date:mime-version; bh=O2XeLb5WZElAhteE62KF8tzaYC7LHnqkOc/wf8hE2W0=; b=HLe5U6iVct988cWNjy0yEmWVkDsArEg+co0z9kDGs0Vd4tPehsjEtbjghotEvST4KL hS4QPASFluAbPwv0mUvIMssV3ID7vnoq6VDDvknmS6bUgQu289Ybf/YDEef1XXCnvi3U 840DZaA7ZBHLeUdlFimPWvpx4jhaHyKseg9s2fWe8itChwID7Fekwqg0mD+X0Ree+Ubt HHcVVtwmQfyTZldm+7HXez/bCZtnDqLvbbbTGbRknLSzTrqaJ2SX/ehBJvMAg6py7OiZ qLGcz77gY8fKP+0qv/lbh5iCK5Qj+lUQ3PFQRofLK3btNdx4fyeWqTEfnbblUjtWbJrR hCaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dz12-20020a0564021d4c00b0043d58fba67csi3100434edb.312.2022.08.19.04.03.01; Fri, 19 Aug 2022 04:03:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348105AbiHSKdX (ORCPT + 99 others); Fri, 19 Aug 2022 06:33:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347614AbiHSKdV (ORCPT ); Fri, 19 Aug 2022 06:33:21 -0400 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D74A32B4; Fri, 19 Aug 2022 03:33:14 -0700 (PDT) Received: (Authenticated sender: contact@artur-rojek.eu) by mail.gandi.net (Postfix) with ESMTPA id 40ECBE000B; Fri, 19 Aug 2022 10:33:09 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 19 Aug 2022 12:33:08 +0200 From: Artur Rojek To: Andy Shevchenko Cc: Paul Cercueil , Jonathan Cameron , Dmitry Torokhov , Chris Morgan , "open list:BROADCOM NVRAM DRIVER" , linux-iio , Linux Kernel Mailing List , linux-input Subject: Re: [PATCH 3/4] iio: add helper function for reading channel offset in buffer In-Reply-To: References: <20220817105643.95710-1-contact@artur-rojek.eu> <20220817105643.95710-4-contact@artur-rojek.eu> Message-ID: X-Sender: contact@artur-rojek.eu Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham 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 2022-08-19 10:17, Andy Shevchenko wrote: > On Wed, Aug 17, 2022 at 1:58 PM Artur Rojek > wrote: >> >> This is useful for consumers that wish to parse raw buffer data. > > ... > >> +int iio_find_channel_offset_in_buffer(struct iio_dev *indio_dev, >> + const struct iio_chan_spec >> *chan, >> + struct iio_buffer *buffer) >> +{ >> + int length, offset = 0; >> + unsigned int si; >> + >> + if (chan->scan_index < 0 || >> + !test_bit(chan->scan_index, buffer->scan_mask)) { >> + return -EINVAL; >> + } > > Have you run checkpatch? The {} are redundant. But personally I would > split this into two separate conditionals. I did run checkpatch on it - all patches were ready for submission. I don't find the {} redundant for multi-line statements, like this one, and I personally prefer to check conditions that return the same error type together. > >> + for (si = 0; si < chan->scan_index; ++si) { > > Just a side crying: where did you, people, get this pre-increment > pattern from?! > >> + if (!test_bit(si, buffer->scan_mask)) >> + continue; > > NIH for_each_set_bit() > >> + length = iio_storage_bytes_for_si(indio_dev, si); >> + >> + /* Account for channel alignment. */ >> + if (offset % length) >> + offset += length - (offset % length); >> + offset += length; >> + } >> + >> + return offset; >> +} >> +EXPORT_SYMBOL_GPL(iio_find_channel_offset_in_buffer); > > Same Q as per previous patch: IIO namespace?