Received: by 10.223.185.116 with SMTP id b49csp8748082wrg; Fri, 2 Mar 2018 07:17:43 -0800 (PST) X-Google-Smtp-Source: AG47ELtXC4Yo/EZ3VILwYbe2OVQ+SKnGk+IAV4Ye0Lm0+5Ye8yqMwxXFejLHUVCdCpuwMApYi+Ns X-Received: by 10.101.91.3 with SMTP id y3mr4841760pgq.149.1520003863109; Fri, 02 Mar 2018 07:17:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520003863; cv=none; d=google.com; s=arc-20160816; b=WenyfB0otKjGdFqvjwGUNxV10RdcY7a3uQTDSQKmYd4530fuqgBVI1C9XZxZEV18Sa 0qQbbRo1dd9XfhgpJrLloZH1vFnXKo4516RyG75vRRREl8a16jXFgsQ8lqsPF+OkTpnl AMgPes07myIvVmVq/ucDcFpVDBAXGLMgAIxJFeflTc8i/n7a7WXnT7wUiIlXug/yqwh1 BSvbwS1r0a6U0rZzLtP8O1yMJfp2B8iiczO3tcGs/8jgR2r6P7ljL/zu6+2JS1rcDBzR c+VEzdETS0yPl+HKMvGrbAJt9Td4Pz77ba2tGVjJ8omLwg4M6vaQGmlHH9E+O1iNct7O +qqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=ZGjrZ2GKJSf9ezPQc3AeiNwavQ7dxMr8+wfsdXHi57U=; b=nkiI/S8c1xJEkxzUPEV84ihlX8RjHePrZl7bqxjh1kxL/A9rkELMNEnNvxV/IiOVPO wi2HsCN/6Gh0OjPRP0bEJ/wSZGWdt/tgX5sjCQfuCAEck4b7f0dAVuO0N59Tt4HiP7ok tBNi6oB5Ylo76sTLIC6T7V2zpK4YDHwCeVisnQBpyvH88SLAoWQu4Kgv10aS6gn4vPey daB2o7ddXnR/yvlHI5kaWzcop1Y09pZMYcMF1bfdASsdNgAr7dgJ1G0OtfC9aY08RYYn Ji7bZLloB01oHV2hWG4NybovvcF2ZOrys0VAVaYvw8Wng/febRvXnFZPsHA2ytifo7xs yb6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p13si4124023pgn.721.2018.03.02.07.17.28; Fri, 02 Mar 2018 07:17:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423264AbeCBMQc (ORCPT + 99 others); Fri, 2 Mar 2018 07:16:32 -0500 Received: from ozlabs.org ([103.22.144.67]:53005 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423042AbeCBMQ2 (ORCPT ); Fri, 2 Mar 2018 07:16:28 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 3zt7ZL0d0Jz9s5R; Fri, 2 Mar 2018 23:16:25 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Rob Herring Cc: devicetree@vger.kernel.org, "linux-kernel\@vger.kernel.org" , Mark Rutland , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev Subject: Re: [PATCH] powerpc: dts: replace 'linux,stdout-path' with 'stdout-path' In-Reply-To: References: <20180228224406.7049-1-robh@kernel.org> <87606ga8bv.fsf@concordia.ellerman.id.au> Date: Fri, 02 Mar 2018 23:16:24 +1100 Message-ID: <87k1uuwu3r.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Herring writes: > On Wed, Feb 28, 2018 at 7:33 PM, Michael Ellerman wrote: >> Rob Herring writes: >> >>> 'linux,stdout-path' has been deprecated for some time in favor of >>> 'stdout-path'. Now dtc will warn on occurrences of 'linux,stdout-path'. >>> Search and replace all the of occurrences with 'stdout-path'. >> >> This patch looks OK. >> >> But please remember that not all device trees are generated with dtc, we >> still have machines in the wild that have firmware which use >> "linux,stdout-path" and may never be updated. > > Absolutely. The core code still supports both. Phew ;) It has prompted us to look at various firmware pieces and some we can update to start using the new property or both. It's still going to be many years before we can actually remove support for linux,stdout-path though. > The only scenario I could come up with is someone has an old > bootloader that only understands linux,stdout-path and modifies it and > they update the dtb. We may end up with both properties with > stdout-path taking preference. Yeah I think this is fairly safe, and in the unlikely case it does cause a problem we can always back the change out for an individual file. cheers