From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A227C38159 for ; Wed, 18 Jan 2023 17:21:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229934AbjARRVp (ORCPT ); Wed, 18 Jan 2023 12:21:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbjARRVm (ORCPT ); Wed, 18 Jan 2023 12:21:42 -0500 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D56DD4A1C8; Wed, 18 Jan 2023 09:21:39 -0800 (PST) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 30IHLDRZ004442; Wed, 18 Jan 2023 11:21:13 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1674062473; bh=6WadCtvk8UAcJIveU7R2rxQCXinRZfK5AQ/s+qIEVrw=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=uaZSGsUxBR1lBWbXccHBx+jZ+VhDJtiDyfvMFxQshGCCa0lwWBEhfuGR+fApogMmU 7HVneSWTwUKYEa7DXLwhAUpPvKBWbYfBaS4LTCP+rfHfqwBduOFufKmUTSS7HiRDf3 rtw0M9qIzvZqqmYYNLu5xMNNsdp/erhcbcuLFJ3E= Received: from DFLE107.ent.ti.com (dfle107.ent.ti.com [10.64.6.28]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 30IHLDmh031418 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Jan 2023 11:21:13 -0600 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE107.ent.ti.com (10.64.6.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16; Wed, 18 Jan 2023 11:21:13 -0600 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16 via Frontend Transport; Wed, 18 Jan 2023 11:21:13 -0600 Received: from [10.250.235.217] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 30IHL7H8109811; Wed, 18 Jan 2023 11:21:08 -0600 Message-ID: Date: Wed, 18 Jan 2023 22:51:07 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH net-next v6 1/3] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add J721e CPSW9G support Content-Language: en-US To: Krzysztof Kozlowski , Geert Uytterhoeven , Siddharth Vadapalli CC: , , , , , , , , , , , , , References: <20230104103432.1126403-1-s-vadapalli@ti.com> <20230104103432.1126403-2-s-vadapalli@ti.com> From: "Raghavendra, Vignesh" In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/17/2023 10:47 PM, Krzysztof Kozlowski wrote: > On 17/01/2023 14:45, Geert Uytterhoeven wrote: >> Hi Siddharth, >> >> On Wed, Jan 4, 2023 at 11:37 AM Siddharth Vadapalli wrote: >>> Update bindings for TI K3 J721e SoC which contains 9 ports (8 external >>> ports) CPSW9G module and add compatible for it. >>> >>> Changes made: >>> - Add new compatible ti,j721e-cpswxg-nuss for CPSW9G. >>> - Extend pattern properties for new compatible. >>> - Change maximum number of CPSW ports to 8 for new compatible. >>> >>> Signed-off-by: Siddharth Vadapalli >>> Reviewed-by: Rob Herring >> >> Thanks for your patch, which is now commit c85b53e32c8ecfe6 >> ("dt-bindings: net: ti: k3-am654-cpsw-nuss: Add J721e CPSW9G >> support") in net-next. >> >> You forgot to document the presence of the new optional >> "serdes-phy" PHY. > > I think we should start rejecting most of bindings without DTS, because > submitters really like to forget to make complete bindings. Having a DTS > with such undocumented property gives a bit bigger chance it will get an > attention. :( > Agree, bindings should have been better tested against real DTS. But for reviewers, this been a bit of chicken-egg problem. Bindings and driver changes have to go in first and via "subsystem" trees while DTS patches have to go via "arch" tree. So, they get posted separately. One may not see DTS patches (and thus user of the bindings) until bindings reach Torvalds' tree. So, user of bindings will only appear in the next kernel release cycle (at which time they do get flagged due to failing make dtbs_check but its bit late). Wondering how others are managing the same ? Regards Vignesh