From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90E9438E5E9; Thu, 26 Feb 2026 07:27:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772090874; cv=none; b=DYVpasetSWUsWu/d1oiu9aCoIB6f/JYiSlOhVXQYK49YFESht/UfhpQ97OhX3qo7GWDRUNg603SyfBftf8ArwyobMQgtbqe3yBy53VKuKzpHGDpRNw7i56rjSdX+ca90TCtotd8289RNXH11G0UOIAeYy7R/QVVbSF7Nw0ADOeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772090874; c=relaxed/simple; bh=ejKY8cckU0ZMHpQ2P4ITpVBIoo3BVhnF6hFc7Qr3r3I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S53qizKqhhJsQjvDrTVKYXLX8e+X77D46bH+dotGYmer+0uGfiWOdfOdAE3K6CjUVw7nOtJFOTxBAqlT2YKazghTcWdEdYKl1t85474fXZmwwAcl5v/Ek5P1yV632VvQ9AOW90gaGfZuQQ0/xD1LzM/7PI5xwCvHhNDhd1xJceM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=YrPHXMMi; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="YrPHXMMi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772090871; x=1803626871; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ejKY8cckU0ZMHpQ2P4ITpVBIoo3BVhnF6hFc7Qr3r3I=; b=YrPHXMMimudjNW7xyZy/sxvur4WpVI1hrbE9UpUGv8G6tz+fCVBrs3mD PoiV88qxghtc0nIIQSrUNMxoX6CooPU3otrDf/6lPTyNKMFgUZP74EKKr S7mYek5vsg6IB5A90/PMrQ23ylxAzQxiCsV5lngf4+aaQ8AfzT6VWHSLj AbDbpbULiJkjXV6ewnnZHKbD+zbKR95W42ctJNYDD4a1oEpwa3dZ0+rt3 DCHku/2by7AIpIS+q9OUNeRfBlqOaTRvxdU+n1uwnnP4AcyHMwUn/mPYS jgsNQ6pYNBSwEaoYO47WFGQvrE+mG5NEE+H8PhO0JRkvCW5s4uu3fK/5W A==; X-CSE-ConnectionGUID: 6lV3yfX9TaqU1NmngZXhmQ== X-CSE-MsgGUID: wJsScsgjQu+xAFFrSJmY0g== X-IronPort-AV: E=McAfee;i="6800,10657,11712"; a="73054258" X-IronPort-AV: E=Sophos;i="6.21,311,1763452800"; d="scan'208";a="73054258" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2026 23:27:50 -0800 X-CSE-ConnectionGUID: VDCYjIxuTk+8jwXAp1dydA== X-CSE-MsgGUID: SuaDiaT7RMi3x+CI0z2d1g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,311,1763452800"; d="scan'208";a="254242969" Received: from dhhellew-desk2.ger.corp.intel.com (HELO localhost) ([10.245.244.167]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2026 23:27:49 -0800 Date: Thu, 26 Feb 2026 09:27:46 +0200 From: Andy Shevchenko To: Brian Mak Cc: Lee Jones , Herve Codina , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] mfd: core: Preserve OF node when ACPI handle is present Message-ID: References: <20260225232105.454931-1-makb@juniper.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260225232105.454931-1-makb@juniper.net> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Wed, Feb 25, 2026 at 03:21:05PM -0800, Brian Mak wrote: > Switch device_set_node back to ACPI_COMPANION_SET, so that the ACPI device_set_node() ACPI_COMPANION_SET() // but see below. > fwnode does not overwrite the of_node with NULL. > This allows MFD children with both OF nodes and ACPI handles to have OF > nodes again. Do you have a real use case? Can you elaborate more (platform, drivers being involved, et cetera)? ... > - device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent)); > + ACPI_COMPANION_SET(&pdev->dev, adev ?: parent); As a quick fix this may be fine, but it needs a big FIXME explaining that this is actually a design limitation of fwnode that doesn't allow proper sharing and stacking. Bouncing back to ACPI_COMPANION_SET() also doesn't feel right as it hides the real thing here, and real thing is the primary/secondary fwnode types that we need to care of. Just call set_primary_fwnode() directly. It helps also to get rid of ACPI_COMPANION_SET() calls where it may be replaced with simple device_set_node(). -- With Best Regards, Andy Shevchenko