Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1878966pxb; Fri, 24 Sep 2021 14:14:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyc82BewEB8yJ+SPgzut+qZsLa1/oG740z3NXL4MrVo2xTuvE1F9LhUy8PfjDgaRuDZIFeD X-Received: by 2002:a50:d98d:: with SMTP id w13mr7615791edj.51.1632518084835; Fri, 24 Sep 2021 14:14:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632518084; cv=none; d=google.com; s=arc-20160816; b=nDd6jfFz32J27woK6rhKPgROb430zgv67S57wVjJ1Ef/7ckSi6eMC5eO8HNZw4aZDA ezKcjBKQeXZX55cl6jKeIufntV7eLLD2ZI2P7KoAdMyIGbjxcF7bXbCutQfpZ7NaVogL cPyKS9OB5dDrm4i1FweXlyQA4Ygq2XbPLtBpuRMP5e9bk9pcxxhWc1Z7qtZI3yeIbGbn 4+IiSx8dKtgUkzqmvDPPG0hIPDR8EvLAa+muy9rRm+e6oKF6JJZPFgNgRd84MxX8ckvv QuFRLr1Kw5D75XnZHNvrl61ooAhynTT15StMS7J2zeBMQRQrGLPj9Z7ICjFZlBu5iV1s jR3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=VTW26QISeUHwM/qRyY199/5lvvf3mRE4t9mjRGV1MHs=; b=zGzwZH9iOEemxu1MYbx0//X8+4XXJpnzjlF5V54ZdYJS82w1q+7S3Im458Xl9Ggtts wMdWcGnUteWfJIpBHO9FG9qdqEvGxRGg2JumDKDjHxfxT97iVE1UD5BJfNEKpxE+tts4 yEjeJpTdzM7lvUbjnZ+YdyNDXYOlS5aCw3447sNgHRPv49VGQEl5Jf7cobBZ34sTXvYU qo+bARyCHFAR4jPHO4cgSNZvyJ0k8UEnnUtlnbvUYIkfh4J5/NwFjWnLzkGTTojR8pbv eP5CyZzbqD4QR4Y7dnxSFKT6VuBbHNiyYO4wt+y18EJUy/69gBWx+TV8m615tuIV876s KhHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=o+eNGW8g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l7si1658014edk.342.2021.09.24.14.14.21; Fri, 24 Sep 2021 14:14:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=o+eNGW8g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347389AbhIXQbC (ORCPT + 99 others); Fri, 24 Sep 2021 12:31:02 -0400 Received: from fllv0015.ext.ti.com ([198.47.19.141]:57642 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244892AbhIXQbC (ORCPT ); Fri, 24 Sep 2021 12:31:02 -0400 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 18OGTL2r108832; Fri, 24 Sep 2021 11:29:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1632500961; bh=VTW26QISeUHwM/qRyY199/5lvvf3mRE4t9mjRGV1MHs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=o+eNGW8g4FUnvb6hMc8Zs/kpXpFjrkftMyW5K+eopGXa0rKDBcfT08U4nx41nMBQo YpY+DXGXWjsughe0ZuISMbLTjCW1LKwOoeO46q8VanpwahavGN+Y3QdhHoDh8nDU5W XfKvb/F7lnhIl/CJiwDtDmKm68w1XQApyWMqwXus= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 18OGTL7W040181 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Sep 2021 11:29:21 -0500 Received: from DFLE108.ent.ti.com (10.64.6.29) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Fri, 24 Sep 2021 11:29:20 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Fri, 24 Sep 2021 11:29:20 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 18OGTKZA086642; Fri, 24 Sep 2021 11:29:20 -0500 Date: Fri, 24 Sep 2021 11:29:20 -0500 From: Nishanth Menon To: Suman Anna CC: Sinthu Raja , Rob Herring , Mathieu Poirier , Bjorn Andersson , Ohad Ben-Cohen , , , , , Sinthu Raja , "Nagalla, Hari" Subject: Re: [PATCH V3 2/2] dt-bindings: remoteproc: k3-dsp: Remove board-specific compatible from DT example Message-ID: <20210924162920.mvnzcibfm7s265us@boxing> References: <20210917095426.19277-1-sinthu.raja@ti.com> <20210917095426.19277-3-sinthu.raja@ti.com> <4d43e927-3998-e9a9-87a6-6036b769a975@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4d43e927-3998-e9a9-87a6-6036b769a975@ti.com> User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11:10-20210924, Suman Anna wrote: > Hi Sinthu, > > On 9/17/21 4:54 AM, Sinthu Raja wrote: > > From: Sinthu Raja > > > > The example includes a board-specific compatible property, this is > > wrong as the example should be board agnostic and gets in the way of > > additions for newer platforms. Replace the same with a generic soc > > node. > > What board specific property? This description looks wrong. See https://lore.kernel.org/all/1631794913.472895.1119414.nullmailer@robh.at.kernel.org/ > > > > > Fixes: 2a2180206ab6 ("dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs") > > What error are you trying to fix exactly? The example used below is actually how > it exactly appears in the J721E dts files, and there are no errors with > dt_binding_check. The rproc binding should have nothing to do with j721e SoC node description. it should describe the rproc node that is described in binding. > > This is more a cleanup than a fix. You can look through the original binding > submission patches to see why it is done like this. This is blocking any updates we would want to do in k3.yaml. > > If this is triggered by the changes you are making to k3.yaml file as part of > the J721E EAIK changes, then you probably may want to look at how you are doing > that again. Looks like the k3.yaml file is being modified now to enforce > "board-compatible", "soc-compatible" which may have triggered an error in this file. > > Please evaluate if you need to modify it to support just the "soc-compatible" as > one of the items. See above link. This is not to do with eaik / sk. I am trying to standardize the board definitions in yaml for k3 and this binding specifically is getting in the way. I still don't understand what your contention is here. Are you arguing that the binding example is correct and should be tied to a platform? Yes, I know I can introduce oneOf and a little more intricate solution, but besides that, i disagree that a rproc binding should even have SoC specific top level node description in it. a) rproc.yaml does'nt even describe the SoC. soc.yaml does. b) The node property examples are supposed to be examples not tied to a specific SoC. > > Signed-off-by: Sinthu Raja > > --- > > > > Changes since V2: > > * review comment updates, including simplifying the changes, commit > > message and $subject updates. > > > > V2: https://lore.kernel.org/all/20210818074030.1877-1-sinthu.raja@ti.com/ > > V1: https://lore.kernel.org/all/20210817152005.21575-1-sinthu.raja@ti.com/ > > > > .../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml > > index 6070456a7b67..5ec6505ac408 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml > > @@ -133,9 +133,7 @@ unevaluatedProperties: false > > > > examples: > > - | > > - / { > > - model = "Texas Instruments K3 J721E SoC"; > > - compatible = "ti,j721e"; > > + soc { > > While this may be resolving the dt_bindings_check you might be seeing with the > modified k3.yaml, note that "soc" property is not used on K3 dts files, you > might be creating confusion for people who look at this example and the actual > usage. It is a common usage model. NOTE: these are example nodes and NOT meant as SoC representation. I dont see the confusion. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D