From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 7B7FD381B14; Mon, 23 Mar 2026 22:12:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774303935; cv=none; b=GCerr6/vFEvXynE9FYVJVV7J5ZzRK0M4BSt80zzHc7ZkASv2DtBeO7L69L48g2JxecfnkN402m+7y/Li8hqUt5yFbCaa9yThxT0/3ok5W6PiOWZauX2+b7yhsK8KatJvVg8BArrSOIi4bBBwAQiDfRFJT3R0JXUeqhVsRuQE7hQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774303935; c=relaxed/simple; bh=3xLIvwqrrXfWdoPtAt7OK3eVmeQqeYbfqRtKss4uPX0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SsOCufXk7nXctT8FmxnEAavFvqpC2+UGwqdqX5Jz7gG0SUPxotrydXlEkjnnKqfROgx4Ui3ngSf/0kFGIfXzlsPgZaXGfEPmmqyuzEW0xbqMHWgT3xuEDDgy0UO23t7AHiqUnz35qloo93eHSRctYzgkFXtyh2S7LLaXmfz5wZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=noCTwJeM; arc=none smtp.client-ip=156.67.10.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="noCTwJeM" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=SI0+KwkPfwgoDdX+0jEvH5cFTJRTk67LUQ/ONMeOpow=; b=noCTwJeMau3v7UV4VnKCLpWr8W hRXYUl4+OExs9pxY2TJcr2o32iliV9RSn3RC+oFjgYV3efZnpsd8Du461lFenp5kt1BIelV4DQcSa W2WRCGcQidhFzFUWZuanxinEGa7W4CUzIfW5/C4vR82SiVdrk1Xqrb1bwK2BKSLS5DeA=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1w4nV8-00D0AX-Ki; Mon, 23 Mar 2026 23:11:58 +0100 Date: Mon, 23 Mar 2026 23:11:58 +0100 From: Andrew Lunn To: Dmitry Torokhov Cc: Mark Brown , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vinod Koul , Neil Armstrong , Liam Girdwood , Lee Jones , Pavel Machek , Peter Rosin , Heiner Kallweit , Russell King , Moritz Fischer , Xu Yilun , Tom Rix , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-spi@vger.kernel.org, linux-leds@vger.kernel.org, linux-fpga@vger.kernel.org, driver-core@lists.linux.dev Subject: Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode() Message-ID: <09072374-65e7-4792-af7e-97d7df93f9bd@lunn.ch> References: <20260322-remove-device-find-by-of-node-v1-0-b72eb22a1215@gmail.com> <20260322-remove-device-find-by-of-node-v1-4-b72eb22a1215@gmail.com> <360a8b4a-6507-417a-9fc1-c53b14868657@sirena.org.uk> <7d46803e-b285-4e9c-8856-10100fa0ea85@sirena.org.uk> <193e194a-498f-464f-b22c-c283c16db6c1@sirena.org.uk> 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: On Mon, Mar 23, 2026 at 02:41:03PM -0700, Dmitry Torokhov wrote: > On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote: > > On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote: > > > > > How do you handle deprecated OF properties? This is a problem i've run > > > into before. A developer needs an ACPI binding, so they blindly > > > convert from of_ to device_ without engaging brain. As a result, they > > > bring all the deprecated OF properties we want to die into the brand > > > new ACPI bindings. > > > > Honestly that one hasn't really come up much for me - not too many > > deprecated properties. > > Given that we position properties as an ABI even if they are deprecated > we supposed to handle them forever. Newer properties usually offer > benefits over old ones and that is how users get moved over. ~/linux/Documentation/devicetree/bindings/net$ grep -r deprecated * | wc 75 361 4195 So networking has ~ 75 of them. Within the OF world, they are ABI and we need to keep them. But we don't want them in ACPI or any other firmware. Any code looking for properties needs to know what is underneath so it can decide if it should look for the deprecated, OF only property, or not. Andrew