Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp504103pxj; Thu, 10 Jun 2021 06:11:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC2gfX5/F5cMyITsjw6nrvE8f6apprbHLfDv/eYZhWm0VksoPsED9eDBwkXaL+FPhdPy5o X-Received: by 2002:a17:906:4d56:: with SMTP id b22mr4304826ejv.78.1623330699578; Thu, 10 Jun 2021 06:11:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623330699; cv=none; d=google.com; s=arc-20160816; b=OawggRoxquLsKg1DIC5AzprKAVgAcfv6V363pMcgXewonMfUk/ai/4X735GeAncdfC UxYwDr/SOWoOiSjl+SbOIuMi4bs6Yzc1wPFzo6cjQNBd+ukJHMoCMqDu/D/q+CISr78O p3X9G4O2omv+lwOs6At+o3NXuI/IXXCvbXcST/Kp965nRiA6dtrdcLZis9UzSnawPq4i vH6LgsidB30IVZbNbbiLtidsM5aGbcCQN6oTF1sHflsX8gev4OBDq+P3WDHks6Q6o6f1 SJ/IofibKIWmhY3Qks4mUbptyXiT5np64hSW9U7crzgkLfrB5Sl+pHfuXYJiy+YrgvYG SUwA== 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:cc:to:subject:from:date; bh=eYlj8BKCalUqDHY+VG9kV/YLNr1ZmiHl+6nVTMSUV88=; b=oJXE9kbmWlJ4SGIOZQQ6ViEDOgVh3/TW+vi7ErgWy2cYFJFoux8yKeXTz9DTmjfj3M BnZlo9l2AiuugI3LyBi5mFwoNXukjBp8q54dmQ+bE9xFMTKE91kG7ityOoJoUKyGaFqA /o4eSEwaRQnoUzRbZdZw8+0TGSIFYWOxXSmxDkdmUbOwZz67D5Vh6Jb8otieYIL/8z0L 9R+SxqhkVRAi6uuF8PbHZf6QVL+KTT/ejUfSAOZ9SJSizwnqMwhvawCSU/T0vgQH/uf9 L85iCTn5+h6nHhMpMQK+5ofYeac5f4rbwmWyEFy4O/7+VgHAdJJ87vtdMQv3urI5he9M ACMQ== 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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 4si2040430ejr.300.2021.06.10.06.11.14; Thu, 10 Jun 2021 06:11:39 -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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230374AbhFJNJn convert rfc822-to-8bit (ORCPT + 99 others); Thu, 10 Jun 2021 09:09:43 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:55329 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230289AbhFJNJm (ORCPT ); Thu, 10 Jun 2021 09:09:42 -0400 Received: (Authenticated sender: paul@opendingux.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 81C7060009; Thu, 10 Jun 2021 13:07:42 +0000 (UTC) Date: Thu, 10 Jun 2021 14:07:35 +0100 From: Paul Cercueil Subject: Re: [PATCH 1/2] iio: core: Support removing extended name in attribute filename To: Jonathan Cameron Cc: Andy Shevchenko , Jonathan Cameron , Lars-Peter Clausen , Michael Hennerich , linux-iio , Linux Kernel Mailing List Message-Id: In-Reply-To: <20210610140412.000054ac@Huawei.com> References: <20210610124556.34507-1-paul@crapouillou.net> <20210610124556.34507-2-paul@crapouillou.net> <20210610140412.000054ac@Huawei.com> X-Mailer: geary/40.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jonathan, Le jeu., juin 10 2021 at 14:04:12 +0100, Jonathan Cameron a ?crit : > On Thu, 10 Jun 2021 15:58:51 +0300 > Andy Shevchenko wrote: > >> On Thu, Jun 10, 2021 at 3:47 PM Paul Cercueil >> wrote: >> > >> > By default, when a channel has an extended name, it will appear >> in the >> > filename of channel attributes. E.g. if the extended name is >> "aux", the >> > filename of a "sample_rate" attribute will be something like: >> > in_voltage0_aux_sample_rate >> > >> > Add a mechanism to disable this feature. This will be used to add >> a >> > "extended_name" channel attribute. >> >> I'm afraid, NAK. Otherwise, please put an explanation that clearly >> shows that it will be no ABI breakage. >> I.o.w. users for the existing drivers and devices will always get >> those attributes at the same platform configuration(s). >> > > What Andy said. This was a bad design decision a long time back, but > we are stuck with it. > > We have the _label attribute today that is the preferred route > forwards > for new drivers but we can't touch the old ones however annoying it > might > be. You're missing the point here. This patchset only adds a new channel attribute and doesn't change anything else. The "label" is good to have, but that doesn't help me in any way. The problem here is parseability. Cheers, -Paul