From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A0E8C433F5 for ; Sun, 3 Oct 2021 15:41:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D1F761178 for ; Sun, 3 Oct 2021 15:41:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230495AbhJCPnc (ORCPT ); Sun, 3 Oct 2021 11:43:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:41898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230482AbhJCPnc (ORCPT ); Sun, 3 Oct 2021 11:43:32 -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 363B4611C2; Sun, 3 Oct 2021 15:41:43 +0000 (UTC) Date: Sun, 3 Oct 2021 16:45:41 +0100 From: Jonathan Cameron To: Jonathan Cameron , "Rafael J. Wysocki" Cc: Andy Shevchenko , linux-iio , Lars-Peter Clausen , "Michael Hennerich" , Alexandru Tachici Subject: Re: [PATCH 2/2] iio:adc:ad7124: Convert to fwnode handling of child node parsing. Message-ID: <20211003164541.5ffc0b38@jic23-huawei> In-Reply-To: <20210815170951.52378891@jic23-huawei> References: <20210725172458.487343-1-jic23@kernel.org> <20210725172458.487343-3-jic23@kernel.org> <20210727145141.0000230d@Huawei.com> <20210727192013.00003f3c@Huawei.com> <20210815170951.52378891@jic23-huawei> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; 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-iio@vger.kernel.org On Sun, 15 Aug 2021 17:09:51 +0100 Jonathan Cameron wrote: > On Tue, 27 Jul 2021 19:20:13 +0100 > Jonathan Cameron wrote: > > > On Tue, 27 Jul 2021 17:16:07 +0300 > > Andy Shevchenko wrote: > > > > > On Tue, Jul 27, 2021 at 4:52 PM Jonathan Cameron > > > wrote: > > > > On Sun, 25 Jul 2021 23:33:12 +0300 > > > > Andy Shevchenko wrote: > > > > > On Sun, Jul 25, 2021 at 8:22 PM Jonathan Cameron wrote: > > > > > > ... > > > > > > > > > - for_each_available_child_of_node(np, child) { > > > > > > + device_for_each_child_node(dev, child) { > > > > > > > > > > Isn't this > > > > > fwnode_for_each_available_child_node() > > > > > better to use? > > > > > > > > Given we would be extracting the fwnode just to call this > > > > loop, I'd say no, device version makes more sense.. > > > > > > > > > > > > > > ... > > > > > > > > > > So the gaps I see are > > > > > device_get_available_child_node_count() > > > > > and > > > > > device_for_each_available_child_node() > > > > > > > > Do we then fix the fact that > > > > device_for_each_child_node() will call the _available() form > > > > for device tree? That seems inconsistent currently and > > > > I was assuming that was deliberate... > > > > > > I'm not sure I got your point. Mine (see below) is to add the APIs > > > that you want to use as a direct replacement of the corresponding OF > > > counterparts. > > +CC Rafael, > > Rafael, if you have a chance to give input on the questions below it would > be much appreciated. Rafael, if you have a chance to look at this it would be great. > > Thanks, > > Jonathan > > > > > The oddity is that device_for_each_child_node() is a direct replacement > > of the for_each_available_child_of_node() other than the obvious > > use of device rather than the of node. > > > > https://elixir.bootlin.com/linux/v5.14-rc3/source/drivers/of/property.c#L939 > > > > static struct fwnode_handle * > > of_fwnode_get_next_child_node(const struct fwnode_handle *fwnode, > > struct fwnode_handle *child) > > { > > return of_fwnode_handle(of_get_next_available_child(to_of_node(fwnode), > > to_of_node(child))); > > } > > > > So the question becomes whether there is any desire at all to have a > > version of the device_for_each_child_node() that does not check > > if it is available or not. > > > > Looks like it goes all the way back. Rafael, any comment on why the available > > for is used here and whether it makes sense to introduce separate > > versions for looping over children that cover the _available_ and everything > > cases? > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/property.c?id=8a0662d9ed2968e1186208336a8e1fab3fdfea63 > > > > I'm kind of assuming this was deliberate as we don't want to encourage > > accessing disabled firmware nodes. > > > > Jonathan > > > > > > > > > > Both of them I think are easy to add and avoid possible breakage. > > > > > > > > >