Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4041749ybg; Fri, 25 Oct 2019 12:28:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqypi8NoeEf6DZIMdzbo+x3jfkrct3sEMzRkTXIn9iJ2pwweffcfbP2TpkAJ6W1ubdr+F3QR X-Received: by 2002:a17:906:1dd3:: with SMTP id v19mr5154604ejh.35.1572031728537; Fri, 25 Oct 2019 12:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572031728; cv=none; d=google.com; s=arc-20160816; b=Ux40t4zBmJyzc5jmJr5kU3tvMOoQMqY/pYxuvnvkUObUohgTAKuqYoQ8Q9SyuaxAuZ PkbNf0RV/ffdDKZiJB7sCqZJbJl43nuDlCzUIv1OzAp+ACY1H0fOwGkNDTmwS3a2wXm7 BtouDd6g7T9n+/VCYHFjNKRCHXzog7xxaWymed6HStBPE14ceU1G8fFA/hbN+LjE7ng4 oYtMnAjV8ios4dDlxkPpu7mst1deCfE1cqTF5GsJS6mWCozM7rH6AFIECgnnZYdReBYI Q5WZ1wVR2QetPUme5usUuTdrcvEb1l1wPWQ4918ItkG/FPXHkBcEmr8bsaiZvoxYrIOu uWFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature; bh=IGgvgh/q+OAYqVKvM8iI8GZO1WTCoGbOAjWVPRqs/XI=; b=k3eu74Z4rtvjiWB1tW4xQWmQwa5g3rBFLoBVNj3TmqKFbN12UaBTUrMFj41BxYvahJ VMXffyxOuR6t92oFlvhdeQVrR7JSxdBaqymMrwU340OBPcdjfDEJkVC0mU31miHpbNbg ynHFPLMDAKZVWWocnSh1xTtrptsXC4Q9rtwqIlzcNwmTMqhV9cCdhiSjxFZHYjb0Cbc7 Epg5y+RHDxdGuW9XOKra1lzshztypiZw86Q973W75jQ+XOd3iDWhqc1qw41IV1QiPaRG RjGWZeJWB6Xq/p7TBzB7B4lCTZl6Cn5NMvdYLnFeXnXIVYjVxjWiEwvHH35sYcWbd7dg zeCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=PDyWp4Dp; dkim=pass header.i=@codeaurora.org header.s=default header.b=Auk8BWFr; 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 b18si1778946eda.307.2019.10.25.12.28.25; Fri, 25 Oct 2019 12:28:48 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=PDyWp4Dp; dkim=pass header.i=@codeaurora.org header.s=default header.b=Auk8BWFr; 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 S2437374AbfJYHzC (ORCPT + 99 others); Fri, 25 Oct 2019 03:55:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58910 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727275AbfJYHzB (ORCPT ); Fri, 25 Oct 2019 03:55:01 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 66C8E60ECE; Fri, 25 Oct 2019 07:55:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1571990100; bh=U54r6LX0ssw+g8qjLKGHh1Yhi6Sj5o6iNs4ZAFLlmsk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PDyWp4DptCJ+c2ap2wzUz4fI0KeRZqy5pI23Xk5JUlPJrP1QjMto/IkhLFCBYatQe w9j1qNCE8sTG1O267wV5k2aanJoSlQU6HvzIQmHDNe9rQ+lH/frXDVib9Vu+vmO2Lj 1ouHOhcYxMX8lur/8QIqJ/XkYdMk5DsdOufE5n3g= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 6AE8A60B19; Fri, 25 Oct 2019 07:54:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1571990099; bh=U54r6LX0ssw+g8qjLKGHh1Yhi6Sj5o6iNs4ZAFLlmsk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Auk8BWFrXU39kNQrasYkgigZIAjmQlNoLTm9OhiHh7ON9HRrMXwVZ1zo2+kF7gOH7 vmyStNYQg1UbT+vi7H36qwXpW0br4wfITh06/G/y9JqQU8CcKvhLcp0cSQ+TPcZRnr AJc8dDV5IDC7u9vk4EFjf92fgq9TpZOBwHpCyQSo= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Oct 2019 13:24:59 +0530 From: Sai Prakash Ranjan To: Rob Herring Cc: Bjorn Andersson , Mark Rutland , devicetree@vger.kernel.org, Andy Gross , Stephen Boyd , linux-arm-msm , linux-kernel@vger.kernel.org, Rajendra Nayak , Rishabh Bhatnagar , Doug Anderson , linux-arm-msm-owner@vger.kernel.org Subject: Re: [PATCHv2 0/3] Add LLCC support for SC7180 SoC In-Reply-To: References: <20191021033220.GG4500@tuxbook-pro> <2fbab8bc38be37fba976d34b2f89e720@codeaurora.org> Message-ID: <81f57dc623fe8705cea52b5cb2612b32@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-10-25 04:03, Rob Herring wrote: > On Thu, Oct 24, 2019 at 6:00 AM Sai Prakash Ranjan > wrote: >> >> Hi Rob, >> >> On 2019-10-24 01:19, Rob Herring wrote: >> > On Sun, Oct 20, 2019 at 10:32 PM Bjorn Andersson >> > wrote: >> >> >> >> On Sat 19 Oct 04:37 PDT 2019, Sai Prakash Ranjan wrote: >> >> >> >> > LLCC behaviour is controlled by the configuration data set >> >> > in the llcc-qcom driver, add the same for SC7180 SoC. >> >> > Also convert the existing bindings to json-schema and add >> >> > the compatible for SC7180 SoC. >> >> > >> >> >> >> Thanks for the patches and thanks for the review Stephen. Series >> >> applied >> > >> > And they break dt_binding_check. Please fix. >> > >> >> I did check this and think that the error log from dt_binding_check is >> not valid because it says cache-level is a required property [1], but >> there is no such property in LLCC bindings. > > Then you should point out the issue and not just submit stuff ignoring > it. It has to be resolved one way or another. > I did not ignore it. When I ran the dt-binding check locally, it did not error out and just passed on [1] and it was my bad that I did not check the entire build logs to see if llcc dt binding check had some warning or not. But this is the usual case where most of us don't look at the entire build logs to check if there is a warning or not. We notice if there is an immediate exit/fail in case of some warning/error. So it would be good if we fail the dt-binding check build if there is some warning/error or atleast provide some option to strict build to fail on warning, maybe there is already a flag to do this? After submitting the patch, I noticed this build failure on patchwork.ozlabs.org and was waiting for your reply. [1] https://paste.ubuntu.com/p/jNK8yfVkMG/ > If you refer to the DT spec[1], cache-level is required. The schema is > just enforcing that now. It's keying off the node name of > 'cache-controller'. > This is not L2 or L3 cache, this is a system cache (last level cache) shared by clients other than just CPU. So I don't know how do we specify cache-level for this, let me know if you have some pointers. -Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation