Message ID | 20240225142714.286440-1-jic23@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp1599627dyb; Sun, 25 Feb 2024 06:27:52 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVu496FGhAUa74p/IXEoaBtxFCIMWvlmOITk9psBP+Px25MBGIuocSV6Ediniah6yf/k8h55oA2nfQYYNVvZO2osQ3KsA== X-Google-Smtp-Source: AGHT+IEqqvyyZnd3zQxQsID8ZmmtnDRd1yCSZvEJdhOU+Ao3RQAQdbCMYwTmaz08zdd2odvaJXcc X-Received: by 2002:a05:6808:2e87:b0:3c1:90ca:195e with SMTP id gt7-20020a0568082e8700b003c190ca195emr7305369oib.41.1708871271819; Sun, 25 Feb 2024 06:27:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708871271; cv=pass; d=google.com; s=arc-20160816; b=xXTzkuCBEn921JqRZ9aFaQox2I2S8LFSiCwZ3sqsaENOO8ZR4eM+UdT0XWGRAVgFJX DSNrHPel7Tvo0hFYQ2y135BX/KKky68IRnPC44j4ewUdJxmsKKGdiDhaFjz4yoGqYVHa pA5agM+vgFP26Sr/DuTbiykclCstgbTwrxHIPZHyMGu/Skz/R4p+6d2MJb4aoXNRb4Gl XVuhDvtaDRi1z43GwNUPeOKUgpk2DOQjyFgyl59yIOtTYDVSuL7NA7BR9YOHpyoUZDwh EK7a/r3IdAZI+jaqcJXMwOFayT7HuB6/5nbDidN707VRrKll0Gxw54blRcp5PBlaea+N c/Yw== 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:dkim-signature; bh=I3DphvjQ1/SjBnt05LfTvVM+9t7E+yFhCuQCKR9x9F4=; fh=PiZ5V/4sGLDov5cF6A5wY5iqIfZAXRefEy8l5uZe2FU=; b=xwlMbH/tZitHh69N2A7kPLzhMXUgXnF5vOpw8KQGnm+AGhiYSKZieKTxxhiKksaqPo Uo7iYSLQa3mve4vwd6X16eUd5DseXuNsW+Zmv/4kLphLKFw2Y4+OEsHI3BkZ27fjDx7a vGZ5AqWZLxnfJtUvsFybnGc7Y9pSVjWxTMGGUBHArNfVJ7ndywlEHUnFrSafK+MP90RW dgfHIzkxcKCkjYR4AgW2E5TkUQwtb+T3EGkETXlCWa2PJ5jCWqcB14ynr5UjMDVjnzw6 JUmGg8dY4ajQ1ncAmt6l5ekqixd0yA3MKVbiOzQyrs4XaZ8MaLkg0H/q1yuE6ePvrjqa 9rkA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=C9VInWVb; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id fn14-20020ad45d6e000000b0068f2cd94c5esi3095558qvb.346.2024.02.25.06.27.51 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 06:27:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=C9VInWVb; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80097-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 955C81C20AE6 for <ouuuleilei@gmail.com>; Sun, 25 Feb 2024 14:27:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADBEC1401F; Sun, 25 Feb 2024 14:27:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C9VInWVb" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 05DF7C2D0; Sun, 25 Feb 2024 14:27:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708871255; cv=none; b=hsBNPE37ofWWyk0I6XmBoMv1eUzZX9flivGuXfhwNPvkvHVhdVJW8bX4zfx/IOFZ6+wCnhTY6y7XUlfbXmwyL30BcmAxYJPrXj1ABHuTRSbe5HNT6ocCTmVQoHgOZCU374vpYyghm9t90KDcBPxep8L/cEAhVgrlSl8IBBxPngA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708871255; c=relaxed/simple; bh=YxLQapaQ7vM/KWmbNZ9Y8e8vat8a+7NhANYH7fHpT9o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=pAMWmT7FQVQz8HoKR5nfbBnZYr2ei/tbeFtKK1Dvov+NOP+AmVySkdfc/OOq0QJVG1NYN13vWf+GOTc3ZZCYpHfGvniB4c/yqjS85IdWu6j5JLNJ3nJSblsqV88iVdYx3bNtFkVA4/VtTuwXsEGmOdbmdBEkCHhrQSMNozzEdiM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C9VInWVb; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32D20C433F1; Sun, 25 Feb 2024 14:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708871254; bh=YxLQapaQ7vM/KWmbNZ9Y8e8vat8a+7NhANYH7fHpT9o=; h=From:To:Cc:Subject:Date:From; b=C9VInWVbwXhq7/VYYsr5CFe0MbZ/D3QJ11XJD8Ofysdo2Qy4HBJpzrWpvio5TO632 4zypRlIztvW/0Mmf4voX7SGP+gbOled8Jz7CIJk6FkE/aOZRgP/6SYsKU30K+Nnw8P egT8P15d0dWwcdK54Pbb8m504gFgK67faJIPj/rTYCPksaSoLJBzQZ9omjn1/nLx6/ sWYqqNbMOPMS1aLhu07W0idkEmHdVGEarcoj/+9NVJVgjwhc6lOP8X+yiznxlH52UY kMaDIy7pIx7W9ebs3SYr+ctnMcvZZUB1NAjWKmvTHqmItlXKHB1bGQHLgavKGvgv+X RhHOuAkZLVM+Q== From: Jonathan Cameron <jic23@kernel.org> To: devicetree@vger.kernel.org, linux-iio@vger.kernel.org, Rob Herring <robh@kernel.org>, Frank Rowand <frowand.list@gmail.com>, linux-kernel@vger.kernel.org, Julia Lawall <Julia.Lawall@inria.fr> Cc: Peter Zijlstra <peterz@infradead.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, marek.vasut@gmail.com, Jonathan Cameron <Jonathan.Cameron@huawei.com> Subject: [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops. Date: Sun, 25 Feb 2024 14:27:10 +0000 Message-ID: <20240225142714.286440-1-jic23@kernel.org> X-Mailer: git-send-email 2.44.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790625351655121041 X-GMAIL-MSGID: 1791881402586041363 |
Series |
of: automate of_node_put() - new approach to loops.
|
|
Message
Jonathan Cameron
Feb. 25, 2024, 2:27 p.m. UTC
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some discussion occured on previous posting.
https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@huawei.com/
Summary:
* fwnode conversions should be considered when applying this
infrastructure to a driver. Perhaps better to move directly to
the generic FW property handling rather than improve existing
of specific code.
* There are lots of potential places to use this based on detections
from Julia's coccinelle scripts linked below.
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(-)
Comments
On Sun, Feb 25, 2024 at 02:27:10PM +0000, Jonathan Cameron wrote: > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Some discussion occured on previous posting. > https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@huawei.com/ > > Summary: > * fwnode conversions should be considered when applying this > infrastructure to a driver. Perhaps better to move directly to > the generic FW property handling rather than improve existing > of specific code. > * There are lots of potential places to use this based on detections > from Julia's coccinelle scripts linked below. > > 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). I'll let you take it. For the series: Reviewed-by: Rob Herring <robh@kernel.org> I've got some drivers/of/ conversions too, but they are probably next cycle at this point. Rob
On Fri, 1 Mar 2024 16:39:42 -0600 Rob Herring <robh@kernel.org> wrote: > On Sun, Feb 25, 2024 at 02:27:10PM +0000, Jonathan Cameron wrote: > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > Some discussion occured on previous posting. > > https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@huawei.com/ > > > > Summary: > > * fwnode conversions should be considered when applying this > > infrastructure to a driver. Perhaps better to move directly to > > the generic FW property handling rather than improve existing > > of specific code. > > * There are lots of potential places to use this based on detections > > from Julia's coccinelle scripts linked below. > > > > 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). > > I'll let you take it. For the series: > > Reviewed-by: Rob Herring <robh@kernel.org> > > I've got some drivers/of/ conversions too, but they are probably next > cycle at this point. > > Rob Thanks Rob, Whether this makes it for this cycle is probably dependent on whether Linus does decide to do got to rc8 as hinted at as a possibility + whether Greg feels comfortable taking these through his tree (char-misc is the normal path for IIO). I know various people are hoping this series makes it, but if doesn't we can do an immutable tree early next cycle (though obviously that may reduce speed of adoption). We are discussing the equivalent pull request for the fwnode version here: https://lore.kernel.org/linux-iio/2024030239-gift-cabdriver-266b@gregkh/T/#m87e7208820ebf6416a77a2973773b65a087b4796 I've optimistically applied this series to my togreg-cleanup branch and merged that into the togreg branch of iio.git for linux-next to pick up. Thanks, Jonathan