Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4338271imm; Mon, 11 Jun 2018 10:35:40 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK0yI+ozYKGbPNeWH4BCa3HwldGtq83EajywrB22+vDGjHSbVlbgOxqXG4/ZaAYCOsMgU/B X-Received: by 2002:a17:902:a581:: with SMTP id az1-v6mr121171plb.61.1528738540140; Mon, 11 Jun 2018 10:35:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528738540; cv=none; d=google.com; s=arc-20160816; b=k8dWvQlF58ImDjgwd1MP+JIM7f4BAPjTxEt1+RulGy6DJjMNdMBB7cGW6d2KXusbMo D2FK+Iry4Q3MTklqReseqEavC85XbP7gYpEV5OqD341LJo5APLN4nEo85eHaTKvfBRGr Nr7y4SUJRDIzRlMc5HMKeu4w2ZM8vn0mQLd8l4ijFaHquig5ekZam05mMxJw9LngKDkz 3LENobgXODEiwNNWGOiH4pBS3vvqPTDnnq4fBwH508AAeUHhe8FYVU0kCYVEnzdXx93z IDJLLcAm+xMgl8rwxmeSr9XXolxkCChuAyx3OlkJLKswRAck8qNPrz8xkmDdhKSWGytW 16uw== 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:arc-authentication-results; bh=nFQoMU7m2Q+NZTpkGxeZUxN35naG/kD7J3oBIG3bCyk=; b=BzCLM2bBzq+dhUfj/BL9DSHSYX8zpOrV14BPIFZIn2gkEJvWCKZQgwNqHhsSjDOHgq AF/kOWwqf2u0ps2nVTICzBWyVibcVytJlUXO0nw7DFSe22aoFfIjDe4ioTL4o1AEUpKR xSyvpQjzP4S4ehzIurs/sNi2Xxy14yxJitlITfINHI9ylx4ISE1PvujtNRgANX9YqFmW 12QSNpqBAtmVt7FeR0LU9jUhqj7r+uznxKdxh4p2+U46p5CsoCOsYSWKDtzhHIvANcC1 BTWVGhIbp9TFcRpF/k4Hr8QRXftfZoS7F2HxRQLRjrGqm5ksKQJyXVIyaZfoDNZWGuzb 69yw== 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 b19-v6si25343226pge.666.2018.06.11.10.34.55; Mon, 11 Jun 2018 10:35:40 -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 S934013AbeFKQzb (ORCPT + 99 others); Mon, 11 Jun 2018 12:55:31 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:53878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933950AbeFKQza (ORCPT ); Mon, 11 Jun 2018 12:55:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EF4161435; Mon, 11 Jun 2018 09:55:29 -0700 (PDT) Received: from [10.1.206.73] (en101.cambridge.arm.com [10.1.206.73]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A42533F59D; Mon, 11 Jun 2018 09:55:27 -0700 (PDT) Subject: Re: [PATCH 08/20] coresight: dts: Cleanup device tree graph bindings To: Mathieu Poirier Cc: linux-arm-kernel , Rob Herring , Frank Rowand , Mark Rutland , Sudeep Holla , arm@kernel.org, Linux Kernel Mailing List , Matt Sealey , John Horley , Charles Garcia-Tobin , coresight@lists.linaro.org, devicetree@vger.kernel.org, Mike Leach References: <1528235011-30691-1-git-send-email-suzuki.poulose@arm.com> <1528235011-30691-9-git-send-email-suzuki.poulose@arm.com> <20180608212211.GG30587@xps15> From: Suzuki K Poulose Message-ID: <0a213578-c7d7-0ed3-ffc1-afc97d8d1516@arm.com> Date: Mon, 11 Jun 2018 17:55:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/06/18 17:52, Mathieu Poirier wrote: > On 11 June 2018 at 03:22, Suzuki K Poulose wrote: >> On 08/06/18 22:22, Mathieu Poirier wrote: >>> >>> On Tue, Jun 05, 2018 at 10:43:19PM +0100, Suzuki K Poulose wrote: >>>> >>>> The coresight drivers relied on default bindings for graph >>>> in DT, while reusing the "reg" field of the "ports" to indicate >>>> the actual hardware port number for the connections. However, >>>> with the rules getting stricter w.r.t to the address mismatch >>>> with the label, it is no longer possible to use the port address >>>> field for the hardware port number. Hence, we add an explicit >>>> property to denote the hardware port number, "coresight,hwid" >>>> which must be specified for each "endpoint". >>>> >>>> Cc: Mathieu Poirier >>>> Cc: Sudeep Holla >>>> Cc: Rob Herring >>>> Signed-off-by: Suzuki K Poulose >>>> --- >>>> .../devicetree/bindings/arm/coresight.txt | 29 ++++++++++--- >>>> drivers/hwtracing/coresight/of_coresight.c | 49 >>>> +++++++++++++++++----- >>>> 2 files changed, 62 insertions(+), 16 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt >>>> b/Documentation/devicetree/bindings/arm/coresight.txt >>>> index ed6b555..bf75ab3 100644 >>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt >>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt >>>> @@ -108,8 +108,13 @@ following properties to uniquely identify the >>>> connection details. >>>> "slave-mode" >> >> >> >>>> }; >>> >>> >>> For the binding part: >>> Reviewed-by: Mathieu Poirier ... >>>> @@ -140,9 +166,6 @@ static int of_coresight_parse_endpoint(struct >>>> device_node *ep, >>>> rparent = of_graph_get_port_parent(rep); >>>> if (!rparent) >>>> break; >>>> - if (of_graph_parse_endpoint(rep, &rendpoint)) >>>> - break; >>>> - >>>> /* If the remote device is not available, defer probing >>>> */ >>>> rdev = of_coresight_get_endpoint_device(rparent); >>>> if (!rdev) { >>>> @@ -150,9 +173,15 @@ static int of_coresight_parse_endpoint(struct >>>> device_node *ep, >>>> break; >>>> } >>>> - conn->outport = endpoint.port; >>>> + child_port = of_coresight_endpoint_get_port_id(rdev, >>>> rep); >>>> + if (child_port < 0) { >>>> + ret = 0; >>> >>> >>> Why returning '0' on an error condition? Same for 'local_port' above. >>> >> >> If we are unable to parse a port, we can simply ignore the port and >> continue, which >> is what we have today with the existing code. I didn't change it and still >> think >> it is the best effort thing. We could spit a warning for such cases, if >> really needed. >> Also, the parsing code almost never fails at the moment. If it fails to find >> "reg" field, >> it is assumed to be '0'. Either way ignoring it seems harmless. That said I >> am open >> to suggestions. > > Looking at the original code I remember not mandating enpoints to be > valid for debugging purposes. That certainly helps when building up a > device tree file but also has the side effect of silently overlooking > specification problems. Fortunately the revamping you did on that > part of the code makes it very easy to change that, something I think > we should take advantage of (it can only lead to positive scenarios > where defective specifications get pointed out). > > That being said and because the original behaviour is just as > permissive, you can leave as is. Thanks. So can I assume the Reviewed-by applies for the code now ? Suzuki