Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752115AbdGZOcR (ORCPT ); Wed, 26 Jul 2017 10:32:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:53810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbdGZOcO (ORCPT ); Wed, 26 Jul 2017 10:32:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43EDD22CB2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh@kernel.org MIME-Version: 1.0 In-Reply-To: <5978A534.5030008@gmail.com> References: <20170725214427.25768-1-robh@kernel.org> <5978A534.5030008@gmail.com> From: Rob Herring Date: Wed, 26 Jul 2017 09:31:52 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/4] Removing full paths from DT full_name To: Frank Rowand Cc: "devicetree@vger.kernel.org" , linuxppc-dev , "linux-kernel@vger.kernel.org" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 26 On Wed, Jul 26, 2017 at 9:20 AM, Frank Rowand wrote: > Hi Rob, > > On 07/25/17 14:44, Rob Herring wrote: >> This series is the last steps to remove storing the full path for every >> DT node. Instead, we can create full path strings dynamically as needed >> with printf %pOF specifiers (commit ce4fecf1fe15). There are a number of >> remaining direct users of full_name after this series. I don't believe >> there should be any functional impact for those users with the change to >> only the node name (+unit-address). The majority are for struct >> resource.name. This should only affect /proc/iomem display. > > I added a new dependency on full_name in: > > [PATCH v4 3/3] of: overlay: add overlay symbols to live device tree > > You don't need to fix that -- I knew the removal of full_name was coming > and expected to adapt to that change when it came, so I'll take care of > it. It will probably take me two or three weeks to get to it, but that > shouldn't be a big deal since the affected code is a new feature that > is not yet used. Indeed, I had fixed up the print statements, but missed that. Thanks for the heads up. Rob