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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1EC1CC43334 for ; Mon, 18 Jul 2022 18:54:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EkiiRZgFHP2UB6MGX/83EWRtPvrGdrdH54QXgYdCoTw=; b=QnV1SMcB5XwgAm9PdLdHjLEkI3 S90PyBujEUwwIM+qWFKsmUnmUHX5NMyK1pyq6KU1w6H7Rc0udgdlX5gEkMPoVtnE/zGs2O0Mm1kev 1iJGMmK4mXdbFzMRPwmTpv6OtnpF5JuZjlVbPctURn7c/HB3n8VPmtdFzSB2hS+FjYFX4OQKudbmi FdNEQ8lVBHEh9CXZ9dRpO7KhJ1dTCS6MM4a1rklUQuM/wZ6g7gCbgHbSvElzss5nX2Hs2xEZpB/6G UfB8tGw5Vn/4Iyz/e2MlMH83AXSGib/qe2agN7wrftu75vAR696y6ngMFHDjZYTWV14gyfSQZScnn VuoPa17g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDVsZ-0009Om-9k; Mon, 18 Jul 2022 18:54:03 +0000 Received: from mga17.intel.com ([192.55.52.151]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDVsO-0009K5-2F; Mon, 18 Jul 2022 18:53:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658170432; x=1689706432; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=uTLGXZcNL+L1yAPxsxYvJrrXWc9UE0EXaIFLw+I10gc=; b=JWegjbxQoKE3n6yGf8RWnZSgl8NI/nBKknRJEI1fkq2AKR3BV+f3v3C3 Q1P0999bEEO8hpnb3ARxCQP9tTg7xIC/feOvcSad1HYA8mzEcwiRHHFD+ D7gRMbvW6v6jxbSZTyQr5wP8yscjYFYhYNCZNJT/rPAuDlPTizghg2bYc y2RXSnjlK0IeHgJC9EbC8iQdstBr2YBKBj1V+XCLGph+kGtmfVlRZtJaR B3LkSRHJZCiynfTyGsvgt8ka7g1OUjupTA1YLuoSm7o9s/1Zzys+eyV/S XFop+32VH9Z/FjBU+zJHcBZC8YNkJxHLWejfOiOwuXa3i/p+OS43R0cei A==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="266701202" X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="266701202" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 11:53:51 -0700 X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="723961155" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 11:53:43 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1oDVsB-001OOr-1i; Mon, 18 Jul 2022 21:53:39 +0300 Date: Mon, 18 Jul 2022 21:53:39 +0300 From: Andy Shevchenko To: "Russell King (Oracle)" Cc: Vladimir Oltean , Andrew Lunn , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Claudiu Manoil , Daniel Scally , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Greg Kroah-Hartman , Hauke Mehrtens , Heikki Krogerus , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , "Rafael J. Wysocki" , Sakari Ailus , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Woojung Huh , Marek =?iso-8859-1?Q?Beh=FAn?= Subject: Re: [PATCH net-next 2/6] software node: allow named software node to be created Message-ID: References: <20220715201715.foea4rifegmnti46@skbuf> <20220715204841.pwhvnue2atrkc2fx@skbuf> 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220718_115352_164735_8671229B X-CRM114-Status: GOOD ( 37.77 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Mon, Jul 18, 2022 at 09:43:42PM +0300, Andy Shevchenko wrote: > On Mon, Jul 18, 2022 at 02:27:02PM +0100, Russell King (Oracle) wrote: > > On Mon, Jul 18, 2022 at 03:29:52PM +0300, Andy Shevchenko wrote: > > > On Fri, Jul 15, 2022 at 11:48:41PM +0300, Vladimir Oltean wrote: > > > > So won't kobject_init_and_add() fail on namespace collision? Is it the > > > > problem that it's going to fail, or that it's not trivial to statically > > > > determine whether it'll fail? > > > > > > > > Sorry, but I don't see something actionable about this. > > > > > > I'm talking about validation before a runtime. But if you think that is fine, > > > let's fail it at runtime, okay, and consume more backtraces in the future. > > > > Is there any sane way to do validation of this namespace before > > runtime? > > For statically compiled, I think we can do it (to some extent). > Currently only three drivers, if I'm not mistaken, define software nodes with > names. It's easy to check that their node names are unique. > > When you allow such an API then we might have tracebacks (from sysfs) bout name > collisions. Not that is something new to kernel (we have seen many of a kind), > but I prefer, if possible, to validate this before sysfs issues a traceback. > > > The problem in this instance is we need a node named "fixed-link" that > > is attached to the parent node as that is defined in the binding doc, > > and we're creating swnodes to provide software generated nodes for > > this binding. > > And how you guarantee that it will be only a single one with unique pathname? > > For example, you have two DSA cards (or whatever it's called) in the SMP system, > it mean that there is non-zero probability of coexisting swnodes for them. > > > There could be several such nodes scattered around, but in this > > instance they are very short-lived before they are destroyed, they > > don't even need to be published to userspace (and its probably a waste > > of CPU cycles for them to be published there.) > > > > So, for this specific case, is this the best approach, or is there > > some better way to achieve what we need here? > > Honestly, I don't know. > > The "workaround" (but it looks to me rather a hack) is to create unique swnode > and make fixed-link as a child of it. > > Or entire concept of the root swnodes (when name is provided) should be > reconsidered, so somehow we will have a uniqueness so that the entire > path(s) behind it will be caller-dependent. But this I also don't like. > > Maybe Heikki, Sakari, Rafael can share their thoughts... > > Just for my learning, why PHY uses "fixed-link" instead of relying on a > (firmware) graph? It might be the actual solution to your problem. > > How graphs are used with swnodes, you may look into IPU3 (Intel Camera) > glue driver to support devices before MIPI standardisation of the > respective properties. Forgot to say (yes, it maybe obvious) that this API will be exported, anyone can use it and trap into the similar issue, because, for example, of testing in environment with a single instance of the caller. -- With Best Regards, Andy Shevchenko