Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1542810pxb; Thu, 4 Feb 2021 16:15:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJw8uDACtjSejJx+gIrUp0ITMAJc7n9Mw1qZ4iGYt3ZO6E5NMK6Ek6C7jO72u7Xw7RM7HgVm X-Received: by 2002:a17:906:68d0:: with SMTP id y16mr1625987ejr.128.1612484129178; Thu, 04 Feb 2021 16:15:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612484129; cv=none; d=google.com; s=arc-20160816; b=XkETFkPdZrsQVjmZs0HAEQIBv8g4CVPLzEFbsm5ga9oJY4kzKjwJK90I2RAwLiEGk2 /bXdBhJtJmp9lpKQZeY9V/5ZE6vXCN+JShg4rFpRxZSLb3JK+J7eF9Mt4XfDlmqOr4AG 5tM1o6P1sqXbXIJIsiiu6KnLghQp88mHs1nRdigIYjYJM2++VExnNAXaPIpKx4zorHfw HYmEApFnILkz5JhFvNEZiL+XFvlZ3xSjzP+J+h8WL1eKIkLYkvaDF0BpbLs0mJXUA9P0 QHbJhNUV8XFUP073f42PfNnuqNlcG2C4LFTUD3VHTCuQUJK8BNHwmSNoXRHmEHINIhtH udAg== 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=FcwGwCNpcpd+qkLWuVWx4j+sB84HP58bIF6W3jSzKOw=; b=s3EPufCmxfkjsc7zTyLQ9tQbr/O7F3yaIax04nnNXqcJ9+VMuFYKJ8x8LPx/8ozXSU kekrLu2xKSI6dIKyKEwVmENsgNEcjYmV3uLRAntYrNYWSlZkg97XweBM7bRhCnbzakp9 t7sLbOVH05pPz7W+0hIT5dduM5Yk0vookhBM4GEJ04vaKQTnYlZYqwvwwx+T0WREtZ6T 9Bp2ihuygWo9OQ9p1DJtF2cG3rQId6gzOwwNKjwVwMiGCO6gvFanUr/9B0gLFa4oEWoA 0oBsecg+zQjiH/DhrcRgtWRU8KS+naQWJpWKZB0KCkajsGKoMO/RpAeYanxC2aHd+g11 yobQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OwCcrEz3; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q16si4162147ejd.199.2021.02.04.16.15.04; Thu, 04 Feb 2021 16:15:29 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=OwCcrEz3; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236369AbhBDNnf (ORCPT + 99 others); Thu, 4 Feb 2021 08:43:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236324AbhBDNma (ORCPT ); Thu, 4 Feb 2021 08:42:30 -0500 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB39CC061573; Thu, 4 Feb 2021 05:41:49 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id q5so2560860ilc.10; Thu, 04 Feb 2021 05:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FcwGwCNpcpd+qkLWuVWx4j+sB84HP58bIF6W3jSzKOw=; b=OwCcrEz34nwaoYgHVhYEuXLUxN8RsVj2AxTD/T++bzASAocHN6OCmydkROHqxhktJ5 sz3z7SuApibMd7eQmd4xure6C8lCmXKZ/eEzi70plH7RHOgHYxE6vvNbOWnQ6iNcWoVj +2F13KRS4/cf/3nPwnGNBEkdSpQEWBDbfVwVgNnLneIlb5+nz59xHpy3lv/sWEco+xzz 7xJgRhcKcL+Ojf42FcjoXILfFKdKzKZ8b69nuXb8OjhLBljz72vYnyhVv92PJ17p4M8Z jofF6+KxapcXk7914r4cxtm5dCA7165gGVYZqe8vh19cSri8alc71d/nyciiqMxE1BtE v+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FcwGwCNpcpd+qkLWuVWx4j+sB84HP58bIF6W3jSzKOw=; b=mxbKEbEnWWsWnsFt/3UOYnq05wfuWFbMpds5eZ2FlPX6Qrzw1tpcxpdbAqYbzuvGC4 lj4bXh/gYzsum5Gyz6IfWPAU/VgbMG2M8IEmia2a+dg3jb5rZjt5y0MbfBB6at9xNMPQ Gxfywune01ywGqf8VKEzikFHqaTj7wjWyRCfRCcl1Y+uxszKhcXl2ynpvF2bV0h+X6k0 FPxlAZWZa1ZOnFff3WCF6OU5RtHjdCnfFVHVdb3BwYbIwuP2+M9am7LdfdmKYs+4zkAM UGe9v1H/mlE6zleE3ddSfyrMZmrJDKmjoN3H2oRHl/XBQsW6CZhZ54IRzQN5wnok7BIN 6tHg== X-Gm-Message-State: AOAM531jlW9wwL2xMhl/QixjyuFMDkyYLNMOLk1bDFS+7ZNhaPYCqfD8 0lEYro180xbdCx+xJJr6TZELfmu7jh/LzBcAa027mKCpEQY= X-Received: by 2002:a05:6e02:138f:: with SMTP id d15mr6968376ilo.303.1612446109179; Thu, 04 Feb 2021 05:41:49 -0800 (PST) MIME-Version: 1.0 References: <20210201145105.20459-1-alexandru.ardelean@analog.com> <20210201145105.20459-7-alexandru.ardelean@analog.com> In-Reply-To: From: Alexandru Ardelean Date: Thu, 4 Feb 2021 15:41:37 +0200 Message-ID: Subject: Re: [PATCH v3 06/11] iio: core: merge buffer/ & scan_elements/ attributes To: Andy Shevchenko Cc: Alexandru Ardelean , Linux Kernel Mailing List , linux-iio , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , =?UTF-8?B?TnVubyBTw6E=?= , "Bogdan, Dragos" , "Rafael J. Wysocki" , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 3, 2021 at 12:04 PM Andy Shevchenko wrote: > > On Mon, Feb 1, 2021 at 5:28 PM Alexandru Ardelean > wrote: > > > > With this change, we create a new directory for the IIO device called > > buffer0, under which both the old buffer/ and scan_elements/ are stored. > > > > This is done to simplify the addition of multiple IIO buffers per IIO > > device. Otherwise we would need to add a bufferX/ and scan_elementsX/ > > directory for each IIO buffer. > > With the current way of storing attribute groups, we can't have directories > > stored under each other (i.e. scan_elements/ under buffer/), so the best > > approach moving forward is to merge their attributes. > > > > The old/legacy buffer/ & scan_elements/ groups are not stored on the opaque > > IIO device object. This way the IIO buffer can have just a single > > attribute_group object, saving a bit of memory when adding multiple IIO > > buffers. > > ... > > > +static int iio_buffer_register_legacy_sysfs_groups(struct iio_dev *indio_dev, > > + struct attribute **buffer_attrs, > > + int buffer_attrcount, > > + int scan_el_attrcount) > > +{ > > + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev); > > + struct attribute_group *group; > > + int ret; > > + > > + group = &iio_dev_opaque->legacy_buffer_group; > > > + group->attrs = kcalloc(buffer_attrcount + 1, > > + sizeof(struct attribute *), GFP_KERNEL); > > + if (!group->attrs) > > + return -ENOMEM; > > + > > + memcpy(group->attrs, buffer_attrs, > > + buffer_attrcount * sizeof(struct attribute *)); > > kmemdup() ? > Perhaps introduce kmemdup_array(). doesn't add much benefit from what i can tell; and it complicates things with the fact that we need to add the extra null terminator element; [1] if we kmemdup(buffer_attrcount + 1) , the copy an extra element we don't need, which needs to be null-ed > > > + group->name = "buffer"; > > + > > + ret = iio_device_register_sysfs_group(indio_dev, group); > > + if (ret) > > + goto error_free_buffer_attrs; > > + > > + group = &iio_dev_opaque->legacy_scan_el_group; > > > + group->attrs = kcalloc(scan_el_attrcount + 1, > > + sizeof(struct attribute *), GFP_KERNEL); > > + if (!group->attrs) { > > + ret = -ENOMEM; > > + goto error_free_buffer_attrs; > > + } > > + > > + memcpy(group->attrs, &buffer_attrs[buffer_attrcount], > > + scan_el_attrcount * sizeof(struct attribute *)); > > Ditto. continuing from [1] here it may be worse, because kmemdup() would copy 1 element from undefined memory; > > > + group->name = "scan_elements"; > > + > > + ret = iio_device_register_sysfs_group(indio_dev, group); > > + if (ret) > > + goto error_free_scan_el_attrs; > > + > > + return 0; > > + > > +error_free_buffer_attrs: > > + kfree(iio_dev_opaque->legacy_buffer_group.attrs); > > +error_free_scan_el_attrs: > > + kfree(iio_dev_opaque->legacy_scan_el_group.attrs); > > + > > + return ret; > > +} > > -- > With Best Regards, > Andy Shevchenko