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 F314CC636CC for ; Tue, 7 Feb 2023 10:21:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230193AbjBGKVX (ORCPT ); Tue, 7 Feb 2023 05:21:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229925AbjBGKVU (ORCPT ); Tue, 7 Feb 2023 05:21:20 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE2C223C76; Tue, 7 Feb 2023 02:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675765278; x=1707301278; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Y2U9WIJPBm0L0FSDgjHarSz3qorOt0PpIQPRP0xPIhs=; b=P1r2BWA416sRpEVK+ck+im98BF6t1cnVyfrKtoRS8fHn95oIUyaZvSMU q3nNIXwxdWsU/NKXfqwKjkXeBu5pBQzEESZa+1YuxAOFVlFYU40ZbXH6U s8FLS3VQnEP9mX0+icsiS4aqFVHLH0nFsnEk4dHvIzyxwi1VJx68ijTSn Oymr8FRAUPEwhnJQBpFEjs77NJigX8EH6oL8H1D/w4K+EpAi0XK0Uusu6 /rmNryV/FsaycESSYhC3+P5+oNqXgkuHpEingHyYVoUrZKxBwWr+cIIC5 1/JedTcM4j5BKsL++JK3orBI0+t45NmPC+dRp5O3oCHBXGdYPHOfPAdl0 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="328112313" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="328112313" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Feb 2023 02:21:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="697227157" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="697227157" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga008.jf.intel.com with ESMTP; 07 Feb 2023 02:21:04 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pPL5v-003Z31-2O; Tue, 07 Feb 2023 12:20:59 +0200 Date: Tue, 7 Feb 2023 12:20:59 +0200 From: Andy Shevchenko To: Saravana Kannan Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , Cristian Marussi , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Frank Rowand , Geert Uytterhoeven , Magnus Damm , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Abel Vesa , Alexander Stein , Tony Lindgren , Geert Uytterhoeven , John Stultz , Doug Anderson , Guenter Roeck , Dmitry Baryshkov , Maxim Kiselev , Maxim Kochetkov , Luca Weiss , Colin Foster , Martin Kepplinger , Jean-Philippe Brucker , Vladimir Oltean , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v3 04/12] gpiolib: Clear the gpio_device's fwnode initialized flag before adding Message-ID: References: <20230207014207.1678715-1-saravanak@google.com> <20230207014207.1678715-5-saravanak@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230207014207.1678715-5-saravanak@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 06, 2023 at 05:41:56PM -0800, Saravana Kannan wrote: > Registering an irqdomain sets the flag for the fwnode. But having the > flag set when a device is added is interpreted by fw_devlink to mean the > device has already been initialized and will never probe. This prevents > fw_devlink from creating device links with the gpio_device as a > supplier. So, clear the flag before adding the device. ... > + if (gdev->dev.fwnode && !gdev->dev.fwnode->dev) > + fwnode_dev_initialized(gdev->dev.fwnode, false); Please, do not dereference fwnode from struct device. We have dev_fwnode() for that. -- With Best Regards, Andy Shevchenko