Received: by 2002:a05:7208:3188:b0:7e:5202:c8b4 with SMTP id r8csp974873rbd; Fri, 23 Feb 2024 09:07:55 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVMkBgMJDVGrjLOEF/mH8f3c5SGM3fqSXmkmIO1OWrWNoOJBkmbbrHxp4sPYl9uZnQMUalbEFwGZHqgFZu8uobE4fCmu2DIYepqkCT9vA== X-Google-Smtp-Source: AGHT+IFeIbLnT8b9mtOO7YiM6k0DeS/aYGOeHcNP58TexLU0ZCjBIe1ym1TwRYZDOLLiHC3nvmp5 X-Received: by 2002:a17:90a:1b8f:b0:29a:9093:619a with SMTP id w15-20020a17090a1b8f00b0029a9093619amr403680pjc.20.1708708074715; Fri, 23 Feb 2024 09:07:54 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708708074; cv=pass; d=google.com; s=arc-20160816; b=li0N9FTBMkNAPEX3Gy4/lFoY4/x32zVVZe6XQ0PV7SmkOFhFul/Q8zJ6XZabV9TTvC yohJizkpQz+7PUFvux8Kl3o6SFZF1tq19T1s2v35lh4qP1wc8rDtWLWlfs12vKVNablr ils6HMvBNGE7o49AWc8G45J1rE5s9lDbUhqWdpUKSp6mwyEA0TIN7kiGm9P6PGN8fc1y Lw7QJr1z09gVVk08CY4fyoKu7gj8BKaTTk8MddLzC+eQRZSmiy/whydFX91IQI3BfT3v TXCIOvcIjE+3kMYsbflSVwBr05NerON0Bhd3XMFN4oyBzUXBoRpdg3dvu5JC8wpQBuO1 o+Ow== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=UFqTenrx5WcdS6i/ZfTYCDC9zlM9wLPxdIZHR9iWkOM=; fh=g7fbJWj7sZUNdPeRdyzQoI5GgIQeKqaGAjHm4vIVd9A=; b=ZXrSPGJdnci3/gg/WxA+ePOeMg5m6LUpykPm1o2XqyXL587xXyKCaZYomPPG+kEksg +jvcG/FPmULm11LV4+7NrKEH0A6OvI0qq3F+Ob97ZiZ8eK1kIheDAokKijMwAR3NzK9t 7HV0yF7iXQh9ZyQdMZP2kIjEVoHlnDMFXklP81Gz1b6idq4ajZZco4L7OqhnEcMa159h EObqmRAnUVkJJQA7AgY+LQ+iE2HE/S8qFel+h5gyEaFTxYiz5XITer2aLZ89A5cNXsbk /AkpeINw3jY0ZE2p6gk3kJ4AwXyuv+owFpFZIZoSMo/7wx3weBQWr1zTL44+J0o0m/4m 2Jlw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-78750-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78750-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=huawei.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id o8-20020a17090a5b0800b0029a23493f23si1425172pji.73.2024.02.23.09.07.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 09:07:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-78750-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-78750-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78750-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id F3D2FB26ACA for ; Fri, 23 Feb 2024 16:43:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D652A129A76; Fri, 23 Feb 2024 16:42:41 +0000 (UTC) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FB8412AAC7; Fri, 23 Feb 2024 16:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708706561; cv=none; b=KCr7yyUjjKoOoYcfERoXUE+/+GX19GsCa3HdZeYgCbOwrRuGz9gUvfMB8eMg7AqI+PfzqYx6g205FLtCAxsfe29ePhHrIfy+ZYN8zBmeahflFYtnXqYlWGuSKm1L+o9l3FLijdi9aPC/lvU85NOjIsyxfpUHLKiQw6CiI9SXHjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708706561; c=relaxed/simple; bh=IWsuBkee3xCAQ86kme8tbkr6alhrezjCTnJppe/xkIg=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dKIeqXyNtMUQwJpIT/eeFy/IDeKkUoso51nAy7jwt4n5ysJCqrBOcoaGU4Fd9VDonsY1qE3nKn1AsGhCUkH2sLWYkpGMdivZkTrfcfOrQoa1f2pQcEwq9xuUE7lhaWgTOkqHX3kKqWqBYZqu6jwb6MfQZMeFp0hGqMF7z7AA9NM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ThG0f6FZtz67mqV; Sat, 24 Feb 2024 00:38:26 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 78C82140684; Sat, 24 Feb 2024 00:42:36 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 23 Feb 2024 16:42:36 +0000 Date: Fri, 23 Feb 2024 16:42:35 +0000 From: Jonathan Cameron To: Andy Shevchenko CC: , Rob Herring , Frank Rowand , , Julia Lawall , Peter Zijlstra , "Greg Kroah-Hartman" , Subject: Re: [PATCH v2 0/4] of: automate of_node_put() - new approach to loops. Message-ID: <20240223164235.00000e46@Huawei.com> In-Reply-To: <20240223163602.0000697a@Huawei.com> References: <20240223124432.26443-1-Jonathan.Cameron@huawei.com> <20240223163602.0000697a@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100004.china.huawei.com (7.191.162.219) To lhrpeml500005.china.huawei.com (7.191.163.240) On Fri, 23 Feb 2024 16:36:02 +0000 Jonathan Cameron wrote: > On Fri, 23 Feb 2024 17:52:46 +0200 > Andy Shevchenko wrote: > > > On Fri, Feb 23, 2024 at 12:44:28PM +0000, Jonathan Cameron wrote: > > > The equivalent device_for_each_child_node_scoped() series for > > > fwnode will be queued up in IIO for the merge window shortly as > > > it has gathered sufficient tags. Hopefully the precdent set there > > > for the approach will reassure people that instantiating the > > > child variable inside the macro definition is the best approach. > > > https://lore.kernel.org/linux-iio/20240217164249.921878-1-jic23@kernel.org/ > > > > > > v2: Andy suggested most of the original converted set should move to > > > generic fwnode / property.h handling. Within IIO that was > > > a reasonable observation given we've been trying to move away from > > > firmware specific handling for some time. Patches making that change > > > to appropriate drivers posted. > > > As we discussed there are cases which are not suitable for such > > > conversion and this infrastructure still provides clear benefits > > > for them. > > > > > iio: adc: rcar-gyroadc: use for_each_available_child_node_scoped() > > > > Is this the only one so far? Or do we have more outside of IIO? > > > > I'm fine with the code if OF maintainers think it's useful. > > My concern is to make as many as possible drivers to be converted to > > use fwnode instead of OF one. > > > Julia wrote a coccinelle script > __free() cases (53) > https://lore.kernel.org/all/alpine.DEB.2.22.394.2401291455430.8649@hadrien/ Gah. Second time today I've hit the wrong key whilst pasting. loop cases. (73) https://lore.kernel.org/all/alpine.DEB.2.22.394.2401312234250.3245@hadrien/ Scattered right across the kernel. No others submitted yet and there is just the one left in IIO after fwnode conversions. There are other drivers I haven't converted to fwnode for various reasons, but this isn't useful for them as not all call of_node_put(). Some of the other cases will be suitable for fwnode conversion and that is definitely the right first choice in many cases. Agreed, it's down to the OF maintainers to take a call on whether they want this infrastructure or not. No longer matters much to me for IIO as you can see. Jonathan