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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01C5CC433F5 for ; Sat, 5 Feb 2022 18:51:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1381028AbiBESve (ORCPT ); Sat, 5 Feb 2022 13:51:34 -0500 Received: from mga05.intel.com ([192.55.52.43]:1835 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241263AbiBESvd (ORCPT ); Sat, 5 Feb 2022 13:51:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644087093; x=1675623093; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=eyTER7PoTb1xRJJC7VnO+4pzGVOkePxUg2TcCM1e6qg=; b=ScSuaUazyfoCdoXgVx0nhXUS5iCCA8PpS/HgVfm5MWGpMyOGnmB3hTlw 6W0i31+yZfwr0wwi8IIVOlG7Z2N0x1xxRIEKLFORaXFLcvw0hhgIFcmWq 2SfppbE9KNYvkTpfVepNBtUro/efZNEDMrRIOiRDQc2Qbe8UfGrRscO01 xY2VufNPIrB2ufJmYHMBJjXhLIGNoP4oKItYV2tLWfmCTzS4hxCgnFayM SY6pLXzgjMSydsr8La2EG73Pg8kfkU91H9MMLnsK6Pm9FVt0u4fHyw4K3 GcG0WFuN9VdIJ4iG1wEHFC5bkuJB2pXy0Oo61gI8Oh6m0p412q4gkXOb7 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10248"; a="334928669" X-IronPort-AV: E=Sophos;i="5.88,346,1635231600"; d="scan'208";a="334928669" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2022 10:51:33 -0800 X-IronPort-AV: E=Sophos;i="5.88,346,1635231600"; d="scan'208";a="483952943" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2022 10:51:31 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nGQ8l-001LkB-N7; Sat, 05 Feb 2022 20:50:31 +0200 Date: Sat, 5 Feb 2022 20:50:31 +0200 From: Andy Shevchenko To: Jonathan Cameron Cc: Nuno =?iso-8859-1?Q?S=E1?= , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring , Lars-Peter Clausen , Michael Hennerich Subject: Re: [PATCH v3 1/3] iio: dac: add support for ltc2688 Message-ID: References: <20220121142501.151-1-nuno.sa@analog.com> <20220121142501.151-2-nuno.sa@analog.com> <20220205184459.7aa8e5d5@jic23-huawei> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220205184459.7aa8e5d5@jic23-huawei> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, Feb 05, 2022 at 06:44:59PM +0000, Jonathan Cameron wrote: > On Sat, 5 Feb 2022 19:29:39 +0200 > Andy Shevchenko wrote: > > A few comments from me, mostly because I couldn't resist jumping in ;) > Note this is only some of the things Andy raised.... ... > > > +static int ltc2688_channel_config(struct ltc2688_state *st) > > > +{ > > > + struct device *dev = &st->spi->dev; > > > + struct device_node *child; > > > + u32 reg, clk_input, val, tmp[2]; > > > + int ret, span; > > > + > > > + for_each_available_child_of_node(dev->of_node, child) { > > > > device_for_each_child_node() > > This is the old issue with missing > device_for_each_available_child_node() > though can just add a check on whether it's available inside the loop. Didn't we discuss this with Rob and he told that device_for_each_child_node() is already for available only? > > > + struct ltc2688_chan *chan; > > > + -- With Best Regards, Andy Shevchenko