Received: by 2002:a05:7208:3188:b0:7e:5202:c8b4 with SMTP id r8csp821950rbd; Fri, 23 Feb 2024 04:51:36 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWx4bEvUFmtkkdXXrsQgSesGQdv0WIX5yUqRHKSAdP90mkBzOyjBcIXYuJlw+a5t+zrS6coSsdLzJ4KjeHJ3DXshShtUm/NgTpBdIq/gw== X-Google-Smtp-Source: AGHT+IF9IQ/bxvgvzKSBf+jIq0KhvP67IroWsd6dW6cT72dmM2zZO16GO+iEzkgzQYnfQX1hoZY7 X-Received: by 2002:a05:6512:33d6:b0:511:87b7:6d88 with SMTP id d22-20020a05651233d600b0051187b76d88mr1755682lfg.32.1708692696771; Fri, 23 Feb 2024 04:51:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708692696; cv=pass; d=google.com; s=arc-20160816; b=veGbWnOIIs6bnSJXtXlK/ldyaSJF5CzPEBNsZViIvvQjMz63SyoO9ZvjjcA+PTIFp3 YMmHelyJn9KAL3Bg9hgr6zP7yzlHA9RI346qpxJNsznwB7h+HxFzEhGSSz0hVeO66XlG 3lfHuSvQrd7tc238eFDDxTuSlL/3EMzthNSD7BcmbG8ZdiweL4ebVD9iu9nUJjSrGK6s ZP7uWIphd4JDtnWzEdY5Jzlz88ba9io0J4+lg/rhdoQBJUUUZk3mdPaRgWOxVz2rgRq2 LQ1UXX4jxSH8Ta7hod4jWWGBCISlZOJWfxxDy+FAV8W/ehMQpQUKJhqSv1zjVzfYMzSk 0ZIQ== 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:message-id:date:subject:cc:to :from; bh=BmNqPjpCiiIfPfDf2uonOZcPj8W2mDBbf0K6SqCPIO4=; fh=Yi6ySJLnlzcQ1cHAdg2GPzYoHD8fqg7PDZYO61sUDKc=; b=sIphQLSVJJwV6kBBOh9JTmGWmmg5eoQA49c0EdthOLwBVZ+CnpdphT1pefsXAYRwFB AUc/QGKVFi5B/ZQVMipFkOMbdtN5Tg6mmGJ3ySVLzV+aXauFPTFzCmhiRZaP+HiGTFHq n4aOqqq/CZDPwQ5KmJ0kvFyq9kYzQIXgahPbW8eC1ja1kHdIpCKz6QYHSpAQvzwioJ7S GbuVJpBx3gaxe+D9QyHmrerd6cTtJ6moovN5kn9FBQ6fX2fQMSebB1MO7HDNw+w1PZ+G jQIUQs9bAzPmDBnmrJaHxzMiTJ+q7W+zfmyRGAbKfMUZ84okjoIej4nj1SVpNLvfG7Sl scZw==; 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-78313-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78313-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=huawei.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id dz15-20020a0564021d4f00b005643f5aa6aesi5659825edb.4.2024.02.23.04.51.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 04:51:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-78313-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; 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-78313-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78313-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 am.mirrors.kernel.org (Postfix) with ESMTPS id D0BC61F27CC8 for ; Fri, 23 Feb 2024 12:44:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0743D7BAE3; Fri, 23 Feb 2024 12:44:36 +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 17D3B6FBF; Fri, 23 Feb 2024 12:44:32 +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=1708692275; cv=none; b=FY8wDnJJEM+WUhhvYU2C+xGfhZKEIqATKCnipQzlOVKG065c8JRsw1/FN9dAOfvKzTD1zNoXXt323Ngkc2dgrx6tPIQmVpuKFkvWZ8FzJb5nvoFEezq0k7dRE1KSZcZ10GIrmdXVIMGcU7OpHxnmgs+vNlyu0wx9jtghW6ujje8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708692275; c=relaxed/simple; bh=Ql3pU3hgr/HBpSrJX8jkClVU8sHud/H6CmtnLarbOp0=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=iIOd3RDu4KKYxEue9J0LXjHnHHNYonnhsJbyx5M9YLv5g7wX2rM1YSoBDEb23xRBbAG5qHtBOGnBZlZkXNzIK7PHIg+/W7HUpeCTRq57TKEGCL4L0OS5YiwRBBam77dG04sTnvof7f+SLa49LIIwr9doy5JgmXz/A+qll7hKNcs= 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.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Th8kW2Sfdz6K8q3; Fri, 23 Feb 2024 20:40:51 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 45E05140D5A; Fri, 23 Feb 2024 20:44:30 +0800 (CST) Received: from SecurePC-101-06.china.huawei.com (10.122.247.231) 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 12:44:29 +0000 From: Jonathan Cameron To: , Rob Herring , Frank Rowand , , Julia Lawall CC: Peter Zijlstra , Andy Shevchenko , Greg Kroah-Hartman , Subject: [PATCH v2 0/4] of: automate of_node_put() - new approach to loops. Date: Fri, 23 Feb 2024 12:44:28 +0000 Message-ID: <20240223124432.26443-1-Jonathan.Cameron@huawei.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: lhrpeml100004.china.huawei.com (7.191.162.219) To lhrpeml500005.china.huawei.com (7.191.163.240) 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. Ideally it would be good if this introductory series adding the infrastructure makes the 6.9 merge window. There are no dependencies on work queued in the IIO tree, so this can go via devicetree if the maintainers would prefer. I've had some off list messages asking when this would be merged, as there is interest in building on it next cycle for other parts of the kernel (where conversion to fwnode handling may be less appropriate). The outputs of Julia's scripts linked below show how widely this can be easily applied and give a conservative estimate of the complexity reduction and code savings. In some cases those drivers should move to fwnode and use the equivalent infrastructure there, but many will be unsuitable for conversion so this is still good win. Edited cover letter from v1: Thanks to Julia Lawal who also posted coccinelle for both types (loop and non loop cases) https://lore.kernel.org/all/alpine.DEB.2.22.394.2401312234250.3245@hadrien/ https://lore.kernel.org/all/alpine.DEB.2.22.394.2401291455430.8649@hadrien/ The cover letter of the RFC includes information on the various approaches considered. https://lore.kernel.org/all/20240128160542.178315-1-jic23@kernel.org/ Whilst these macros produce nice reductions in complexity the loops still have the unfortunate side effect of hiding the local declaration of a struct device_node * which is then used inside the loop. Julia suggested making that a little more visible via #define for_each_child_of_node_scoped(parent, struct device_node *, child) but in discussion we both expressed that this doesn't really make things all that clear either so I haven't adopted this suggestion. Jonathan Cameron (4): of: Add cleanup.h based auto release via __free(device_node) markings. of: Introduce for_each_*_child_of_node_scoped() to automate of_node_put() handling of: unittest: Use for_each_child_of_node_scoped() iio: adc: rcar-gyroadc: use for_each_available_child_node_scoped() drivers/iio/adc/rcar-gyroadc.c | 21 ++++++--------------- drivers/of/unittest.c | 11 +++-------- include/linux/of.h | 15 +++++++++++++++ 3 files changed, 24 insertions(+), 23 deletions(-) -- 2.39.2