Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp104923ybi; Fri, 14 Jun 2019 19:58:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1aIH3zL1YJtJWsyDzKGYVxJcAWtzJe6VP3SH4yjR1KNfBHPddEYLfHMfWpOZMSkgUy8s1 X-Received: by 2002:a63:ed13:: with SMTP id d19mr31369700pgi.100.1560567488260; Fri, 14 Jun 2019 19:58:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560567488; cv=none; d=google.com; s=arc-20160816; b=ys0ZEDpbcSIeCPQK+vdsKqkmX16YKJTnC2L/f7KW4hI87rnEuXvG/rUSRJC/6yeBiA kSrJZL94NciJhWItbTMA+sVqLroUC9Rx+CNtNUd2fMcc58DPI2lxySPysAydZS5mI2gU iHeAP+ND76zKVeK0nfIOj0AZLRuN9evcVghJ5aueyTTZxNzXW6M9HxNK5kSmZ3pECHEg F4DEAPaYjc8shBwA+Blinp2Dcm2CYzPZxzBP05lLzWP/YeM/QTZMedX6MQki73C3l8w/ zAlIxx905crXIemAUU5TTvI4ddDUh16QBGJimNUlQwPJWwgHvr5P4xL9P+zCAJ0syFuS WH5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=7Jn/qCfDG1VMiV2BK3+InN2xIMk4I8bJ5l6gtVIHboM=; b=XXOo/2hthjFBdKsQd3iPmEoO3wbJg4uAqXAlvWExQVLsmq05PgEHhyuPxkuy40a3zL hMqIxie9RkaKspUq1HRmSK02d3q3bTHc0YS8NjnaZSQObkLOcQMQumAbJhQ0aG+EX6OP FRxNMSQ1QLNTlx/mJt+iopq40KITv1XiSNdbbYNQApltS2U1e9usARuvPsrULofKY6A/ E7cLqkbUcHAVlBZdOrPC9990yaLDhFEBDqCdTXKqy7SEgy9t8HCLXWjo6gkTW1TCcAcX yZpTE7WkvMyP6oWu3QxCJVU+enS9i6YW6jZRa/Pcn9FGWThQ24JfCVY1EGs2ixK7LnBa pqiA== 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 j62si4075208pgc.71.2019.06.14.19.57.52; Fri, 14 Jun 2019 19:58:08 -0700 (PDT) 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 S1726701AbfFOC5h (ORCPT + 99 others); Fri, 14 Jun 2019 22:57:37 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:18620 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725825AbfFOC5h (ORCPT ); Fri, 14 Jun 2019 22:57:37 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id EBD726116911769F74C7; Sat, 15 Jun 2019 10:57:32 +0800 (CST) Received: from [127.0.0.1] (10.133.217.137) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.439.0; Sat, 15 Jun 2019 10:57:29 +0800 Subject: Re: [PATCH next] of/fdt: Fix defined but not used compiler warning To: Rob Herring , Frank Rowand CC: , "linux-kernel@vger.kernel.org" , Stephen Boyd References: <20190612010011.90185-1-wangkefeng.wang@huawei.com> <0702fa2d-1952-e9fc-8e17-a93f3b90a958@gmail.com> <41acc800-1ab8-c715-2674-c1204d546b4f@gmail.com> From: Kefeng Wang Message-ID: <87eb8114-0b52-6324-43b2-aa8193808637@huawei.com> Date: Sat, 15 Jun 2019 10:57:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.133.217.137] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/6/14 21:53, Rob Herring wrote: > On Wed, Jun 12, 2019 at 12:29 PM Frank Rowand wrote: >> >> On 6/12/19 10:00 AM, Rob Herring wrote: >>> On Wed, Jun 12, 2019 at 10:45 AM Frank Rowand wrote: >>>> >>>> Hi Kefeng, >>>> >>>> If Rob agrees, I'd like to see one more change in this patch. >>>> >>>> Since the only caller of of_fdt_match() is of_flat_dt_match(), >>>> can you move the body of of_fdt_match() into of_flat_dt_match() >>>> and eliminate of_fdt_match()? >>> >>> That's fine as long as we think there's never any use for of_fdt_match >>> after init? Fixup of nodes in an overlay for example. >> >> We can always re-expose the functionality as of_fdt_match() in the future >> if the need arises. But Stephen's recent patch was moving in the opposite >> direction, removing of_fdt_match() from the header file and making it >> static. > > Yes, we can, but it is just churn if we think it is likely needed. > > OTOH, we probably want users to just use libfdt API directly and > should add this to libfdt if needed. > > So yes, please implement Frank's suggestion. OKļ¼Œdone in patch v2. > > Rob > > . >