From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 4808F3806D9; Wed, 18 Mar 2026 09:06:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773824814; cv=none; b=WiHAnvIZuhqlEgWJWw40e15wIlpjcIE+t6d9Ye9NH/tpIfQ+IwDGb+coSvQtu4sTNTi5oM6X0wM1XZ5MJ4uVyhBqxDMVBBXC8p/dbZlWtDjRIj35ftzV/Bi57l3ZKB/Vv1qWJITADFGITw/c4A3f2B4XZPgolp4nMPAEm316wLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773824814; c=relaxed/simple; bh=OOpz2QLVOMmh9KY2GRGxQ6h+0tnAzCc8jxynqR/fL8c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Rf4bEBjizwgm8EdOcW3auquIs8OkwfzXAOrXJ2LE94C53ZO64cj1ie2Vrh4/ry1uxGb7Q8xAlL0sgHfCfYSv9uUaVJFr8QHDl12nQTurJUwUcGmuJSvHpWsbqF8RlxhM+eFe3osVfj6A+9qr3n5zdxyEZ814q8OTxJ8tTSPvdNE= 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=VLY1dV3s; arc=none smtp.client-ip=198.175.65.20 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="VLY1dV3s" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773824813; x=1805360813; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OOpz2QLVOMmh9KY2GRGxQ6h+0tnAzCc8jxynqR/fL8c=; b=VLY1dV3sVmWq3gJTWrFSVViPbCnFtyc2GcbLiLD3QqGf5w9n7Tn/sjAg BUbeOdkvfd6Nx8zNp/gLZ/ImnLRD4i3DZNp6sbg6Y5Vn8FOemBvk/Cz1v yDswofBEh6LvGKlVOtV0BDHue5yd++YjKZcJtsbiDXfBM34gEPZ5oIrTU xHRdH3xVbQkIb+rtH3Z5H0xW/qFTyz9pI1QrW77YMNvAzXUZOnoL/IDjk tajQ2tEK0V26vaghBKQ6bbw+koMb9we5D5EswiVCrWldwRgVjI7IIDYIh AJBuEGs7lrQkl+LhOQ0sUQNUes8mPZI84tEvgFWrSeL9BpM57/Mh4WGgh A==; X-CSE-ConnectionGUID: R4xC4tmMTU28wQFRZ0zGew== X-CSE-MsgGUID: IqpuriG9S2yAIoES04+teA== X-IronPort-AV: E=McAfee;i="6800,10657,11732"; a="74573983" X-IronPort-AV: E=Sophos;i="6.23,127,1770624000"; d="scan'208";a="74573983" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2026 02:06:53 -0700 X-CSE-ConnectionGUID: bGaVs8xpTUCoR2u709K5aQ== X-CSE-MsgGUID: hk9DpRDxSG2N5wW8ulwWpw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,127,1770624000"; d="scan'208";a="253045856" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.240]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2026 02:06:44 -0700 Date: Wed, 18 Mar 2026 11:06:41 +0200 From: Andy Shevchenko To: Geert Uytterhoeven Cc: Wolfram Sang , Douglas Anderson , Greg Kroah-Hartman , "Rafael J . Wysocki" , Danilo Krummrich , stable@vger.kernel.org, Andrew Lunn , Daniel Scally , "David S. Miller" , Eric Dumazet , Fabio Estevam , Frank Li , Heikki Krogerus , Heiner Kallweit , Jakub Kicinski , Len Brown , Mark Brown , Paolo Abeni , Pengutronix Kernel Team , Rob Herring , Russell King , Sakari Ailus , Saravana Kannan , Sascha Hauer , devicetree@vger.kernel.org, driver-core@lists.linux.dev, imx@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] device property: Make modifications of fwnode "flags" thread safe Message-ID: References: <20260316154159.1.I0a4d03104ecd5103df3d76f66c8d21b1d15a2e38@changeid> Precedence: bulk X-Mailing-List: stable@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: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Wed, Mar 18, 2026 at 09:41:44AM +0100, Geert Uytterhoeven wrote: > On Tue, 17 Mar 2026 at 08:34, Andy Shevchenko > wrote: > > On Tue, Mar 17, 2026 at 08:26:53AM +0100, Wolfram Sang wrote: ... > > > Thanks for tackling this issue! I agree it should be fixed, just > > > wondered about one thing: > > > > > > > While flags are often modified while under the "fwnode_link_lock", > > > > this is not universally true. > > > > > > Is it a possibility to use the lock in all code paths instead? > > > Because... > > > > > > > struct list_head consumers; > > > > - u8 flags; > > > > + unsigned long flags; > > > > > > ... this change costs some memory on every system. Maybe it can be > > > avoided? > > > > How much memory does it cost? On most 64-bit architectures is +4 bytes, > > rarely +0 bytes, on m68k it might be +2bytes. On 32-bit it most likely > > +0 bytes. I expect that 64-bit machines will cope with this bump. > > On all architectures with natural alignment of pointers and longs, > it won't cost a thing: struct list_head contains pointers, so the > struct must be padded to a multiple of 4 or 8 bytes anyway. > On m68k[*], it will cost 2 bytes, as the existing padding is just a > single byte. > > [*] Iff m68k ever switches to 32-bit alignment, there won't be an > additional cost due to the change of flags here, but of course > there would be a cost all over the place. Thanks! Yes, the worst case is 64-bit architecture with 4-byte alignment. This will cost +4 bytes. But I think we are really wasting time on this part of the discussion (and any similar) as long as nobody targets struct device or any other BIG FAT data type, that will bring much more benefit than saving 4 bytes in some struct fwnode_handle. -- With Best Regards, Andy Shevchenko