Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp726297pxf; Thu, 1 Apr 2021 11:55:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi/sYUwZN0v0D1x8c+yCQuF1Z9pGcVwr4O8nGSWyp7hUfEhT4NORY9j6Gld6XuQOt3CXzH X-Received: by 2002:a05:6e02:1d01:: with SMTP id i1mr7705957ila.171.1617303325003; Thu, 01 Apr 2021 11:55:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617303324; cv=none; d=google.com; s=arc-20160816; b=R3wF8HYlowroPXWnAj05OyrKTHdDc3eO5oZabOyoknSHlrDRnccL+teXZ8s26G01OJ JfqrVMN1defHiqvoVsGxUSH0FNry+3553XooHLI7eMmRuxDU4UjlJ9UcpUFRKNmGtems lmsti2rt4+nFI2PJRAKf1wqQtA9TMlrrQWan0T749DgmxglwPElKbWPKWTLxn5zlB0m8 j8tp0rQStP7BoT3lj3c9eVfUGXyZg8TvTa82EoeJasibPiqm+AVY+oae/VUfT4Y1cTzV HP4togxzm1zvMrJkr69ZGeIPwZD+ovrphgodHBWJdoLxp8Dl+wgBTF3LKxkH82GskCJ0 fQBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=lEU9U6h6wtip0kQYDYPoQv1ZME7bMvcufwWBZTDEVGc=; b=W/tqLkf/vSiiorR+0UFVmkdeIMKUzPv1NyA4AjHSCZ24CF1QH99EFAEV7eKDAATg8V k48+vPwEeJo1vrxLi6aeksIZQMakKNOhl0Z+O/sojI85GFDmqkfSo+UTdSD5F1I40PUZ fPlmnUTBHwTVmPEyYVBkgoadsXKRF0NhHTet/uUAfsNkIE1Y3B27sAT2yV5oLp0orjmA tkqAYHzkVVHi+zVPLMp5M4BgD8cSntBgAs+HHs1iA/PH4f1TFbhb4YXTF3mQB3cm2BAe 1uGPAW5cj1x44m2jGcFs1yuGHXHWGClCekeuBmLDzkvW2XfmiwTTod8CRNN8o1X7fF2x LB5g== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a14si6761187ilm.45.2021.04.01.11.55.11; Thu, 01 Apr 2021 11:55:24 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236767AbhDASwV (ORCPT + 99 others); Thu, 1 Apr 2021 14:52:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:32786 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238339AbhDASh7 (ORCPT ); Thu, 1 Apr 2021 14:37:59 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9787461264; Thu, 1 Apr 2021 15:00:11 +0000 (UTC) Date: Thu, 1 Apr 2021 16:00:20 +0100 From: Jonathan Cameron To: Mauro Carvalho Chehab Cc: Alexandru Ardelean , , , , , , , Greg KH Subject: Re: [PATCH v2 1/5] iio: Documentation: update definitions for bufferY and scan_elements Message-ID: <20210401160020.17537821@jic23-huawei> In-Reply-To: <20210401154408.5f26a3c6@coco.lan> References: <20210217083438.37865-1-alexandru.ardelean@analog.com> <20210217083438.37865-2-alexandru.ardelean@analog.com> <20210401154408.5f26a3c6@coco.lan> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 1 Apr 2021 15:44:08 +0200 Mauro Carvalho Chehab wrote: > Em Wed, 17 Feb 2021 10:34:34 +0200 > Alexandru Ardelean escreveu: > > > Since the new change to the IIO buffer infrastructure, the buffer/ and > > scan_elements/ directories have been merged into bufferY/ to have some > > attributes available per-buffer. > > > > This change updates the ABI docs to reflect this change. > > > > The hwfifo attributes are not updated, as for now these should be used > > via the legacy buffer/ directory until they are moved into core. > > > > Signed-off-by: Alexandru Ardelean > > --- > > Documentation/ABI/testing/sysfs-bus-iio | 85 +++++++++++++++++++++++++ > > 1 file changed, 85 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio > > index d957f5da5c04..f2a72d7fbacb 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-iio > > +++ b/Documentation/ABI/testing/sysfs-bus-iio > > @@ -1118,12 +1118,16 @@ Description: > > > > What: /sys/bus/iio/devices/iio:deviceX/buffer/length > > KernelVersion: 2.6.35 > > +What: /sys/bus/iio/devices/iio:deviceX/bufferY/length > > +KernelVersion: 5.11 > > Contact: linux-iio@vger.kernel.org > > Description: > > Number of scans contained by the buffer. > > The ABI parser doesn't like things like this: > > $ ./scripts/get_abi.pl validate > > Warning: file Documentation/ABI/testing/sysfs-bus-iio#1167: > What '/sys/bus/iio/devices/iio:deviceX/buffer/length' doesn't have a description > > The main reason is that all properties, including KernelVersion, > Contact and Description are associated to a group of properties. > > To be frank, for me that don't work with IIO, the above ABI > description doesn't sound clear. > > I mean, what's the difference between > /sys/bus/iio/devices/iio:deviceX/buffer/length > and > /sys/bus/iio/devices/iio:deviceX/bufferY/length? > > > If the intention is to tell that: > /sys/bus/iio/devices/iio:deviceX/buffer/length > was obsoleted by: > /sys/bus/iio/devices/iio:deviceX/bufferY/length > > IMO, the right thing would be to move the deprecated definition to > Documentation/ABI/obsolete/ > > If, on the other hand, both are completely identical and > non-obsoleted, why to have both APIs? > > Or did you just missed adding a different description for the > new ABI symbols, but this was dropped due to some merge > conflict? You are right that the version with out the index is obsolete but it's only just become so and there are no realistic way we are going to ever be able to remove it however much we encourage userspace to use the new interface. We are stuck with this bit of backwards compatibility indefinitely. I'm fine with moving it and related definitions over to ABI/obsolete if that makes sense. Jonathan > > Thanks, > Mauro