Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3855518iog; Tue, 28 Jun 2022 04:19:04 -0700 (PDT) X-Google-Smtp-Source: AGRyM1thBzwVE7ZrJA99EmaJV0zZWkc9XSqDBj4EgFokdygm1GYwb389e7RamnR8f/w3F0bRMFEw X-Received: by 2002:a17:902:7893:b0:16a:6d44:2556 with SMTP id q19-20020a170902789300b0016a6d442556mr4316206pll.166.1656415144065; Tue, 28 Jun 2022 04:19:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656415144; cv=none; d=google.com; s=arc-20160816; b=oq7jAD46QTgwmMJQ89iiU8D129G7cQZRCIw11dgZJca5418L6ALpB8E5aVCNt6ilAg T8Ib/Leo4NHvtYEm254NPC/k6Xe5m35Hx0n0JV+GFSz/yUXZLMGSY5KwEEWafKilCZo9 HY9Aiz8zwjqLWeld0hzyNdeLg4nLoUPFUs19b08mxVAbkVod7AJU5ZO9z7mjxM8m0eDc hpajueM9K5pqxcpeeDqGHOIQLwxJQ/jy6PIsHwireSr4t6WcABLALzO+d9n/bm2mGg5U XtLVkfZ4D4iA8fJuAqyXAPVl7/3+qX3WuKpo4e4kxIP+/Np0aybMqWQ2g608U1Yh9ylZ RtAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=py7+pLly3u+DedmD3A5E3o+RriPkzj6JEc+WP7uPiVY=; b=mLfpsWXNDCFYWDQSouIxuOX3ps0JiMF04SDbBUJ25u9kgfsq6OdMGv2cHm/g4kmzme 3q6+fDtELzoIZnS8JTok101FCM2K7EYdPo0NZwh1ZDaNy1+adpMOYECaiy4nfsWW3+sS I9oht4jsHo5XyV8TTug7lXIzvScC63IP/wiy19QSd4ioaVpHkOSVUQxnKidU86e2bPpc NwmuIoLmccHcVWh67rHF58GGAG+JazGqGwbEzAzgP9UkrVBCUrkSJnCeHiw1nuW93bYp gVYeLTLMjjdKU3rswUgFto4ZCpmmsNk7ml9zZV2Xz+aMjKR+FJEaaOA7fyAR9mozsc6A 5SZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Qc+NoJCI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y20-20020a1709027c9400b00159071eb8f6si16249053pll.502.2022.06.28.04.18.51; Tue, 28 Jun 2022 04:19:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Qc+NoJCI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345418AbiF1LKv (ORCPT + 99 others); Tue, 28 Jun 2022 07:10:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343969AbiF1LKu (ORCPT ); Tue, 28 Jun 2022 07:10:50 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 656FD2B252; Tue, 28 Jun 2022 04:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656414649; x=1687950649; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Sh8CDNz7phFGpULk8cj2R1XFUA4dQiJJ0YaEGaFVak0=; b=Qc+NoJCIbR0AqRnSi0VFFbJSG2IwiSZqh4dXBQ2hNi47vZKmqkEqbUFy mxacw1wHbF+NZmfzlk2MohZUAWKPdmVEhoroDvBPSLh1Jjk61Y8s0UaDY yOAcB/R5oxVAmjNH3W1qFFi/S0ehBYJJEC3c0TcAl7o/pycr+cNpQe41Z vY38m0pEj6aKkpo+7MBSQwfdAvwK8sDTpB77YqrVWXTdaNAbyLR9HDqA8 WJvV+EOHXwLNAM68wfin4K0sTWJ3o5YtfeCvaa0tDBN2zhMiZnxTNvpKX k1HTwz13WtY5eyyi6LEsfVQ8cL7nozYhYATa7iRXZYLgif/Gz81Dofeso A==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="345708030" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="345708030" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 04:10:48 -0700 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="693066778" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 04:10:46 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1o697E-000wkk-0d; Tue, 28 Jun 2022 14:10:44 +0300 Date: Tue, 28 Jun 2022 14:10:43 +0300 From: Andy Shevchenko To: Michael Walle Cc: "Rafael J. Wysocki" , Rob Herring , Krzysztof Kozlowski , linux-acpi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: fwnode_for_each_child_node() and OF backend discrepancy Message-ID: References: <4e1d5db9dea68d82c94336a1d6aac404@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e1d5db9dea68d82c94336a1d6aac404@walle.cc> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 27, 2022 at 02:49:51PM +0200, Michael Walle wrote: > Hi, > > I tired to iterate over all child nodes, regardless if they are available > or not. Now there is that handy fwnode_for_each_child_node() (and the > fwnode_for_each_available_child_node()). The only thing is the OF backend > already skips disabled nodes [1], making fwnode_for_each_child_node() and > fwnode_for_each_available_child_node() behave the same with the OF backend. > > Doesn't seem to be noticed by anyone for now. I'm not sure how to fix that > one. fwnode_for_each_child_node() and also fwnode_get_next_child_node() are > used by a handful of drivers. I've looked at some, but couldn't decide > whether they really want to iterate over all child nodes or just the enabled > ones. > > Any thoughts? It was discussed at least twice this year (in regard to some new IIO drivers) and Rob told that iterating over disabled (not available) nodes in OF kinda legacy/design mistake. That's why device_for_each_child_node() goes only over available nodes only. So, why do you need to iterate over disabled ones? -- With Best Regards, Andy Shevchenko