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 9AF4CC636CC for ; Tue, 7 Feb 2023 10:28:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231411AbjBGK2x (ORCPT ); Tue, 7 Feb 2023 05:28:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231357AbjBGK2q (ORCPT ); Tue, 7 Feb 2023 05:28:46 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D017123336; Tue, 7 Feb 2023 02:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675765723; x=1707301723; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qFKo6P9N6kXoK08jHrxIsWsAo99hMsJ26Xtn6cj93Is=; b=iHZ5ODVbMyXB3GZLP6mbShkacHZELDgOhRiyIjD1ZyC+DRyLLHGWxyiW kw4VMhnNxK3C8F7gALP/nh6g6Zb4FdQynS38+dMu2aJ/XIsl7CtRQfcrv 4ACzJ5mLEVAhRDH6cWZGI5oIsh/cjj0EXA3NklTOuiWiA8aGZRHs2zvKf 56hL9D7mgO0yH4wecUv3Sc2YdZszGDNEPvj6O42i2uC1ukHpp4WWZmy9A Q7wkk4giBUJD8c16JEpzjnaGve8G3hJeQprjH+4qiI7eLdd9YnSu5SqBC FZgWj0oFm1dFYhE8Ujbb0EELLNM0GpgubmBYndKXahIZ5gcd9s/WJSdgT g==; X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="356841077" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="356841077" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Feb 2023 02:28:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10613"; a="616762031" X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="616762031" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga003.jf.intel.com with ESMTP; 07 Feb 2023 02:28:32 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pPLD9-003ZAe-19; Tue, 07 Feb 2023 12:28:27 +0200 Date: Tue, 7 Feb 2023 12:28:27 +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: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 07, 2023 at 12:20:59PM +0200, Andy Shevchenko wrote: > 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. Note, with that fixed you may add my Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko