Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2627555pxp; Mon, 14 Mar 2022 00:59:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzTcjHUSCpII1Zcla//1n/3gsJJv2PSAvWc5/NXCa2+dqLlXF7nN1Z0EJiOh929TLs575Jh X-Received: by 2002:a17:90b:1c03:b0:1c6:156d:44e4 with SMTP id oc3-20020a17090b1c0300b001c6156d44e4mr2885853pjb.1.1647244766159; Mon, 14 Mar 2022 00:59:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647244766; cv=none; d=google.com; s=arc-20160816; b=UaCybGSJR+UA7nyPqk64TxflrCrfltyaKF7ZDUWC7O520EwPwJefoTbFOCTs7ZwXkH IpP7kofccOO1KjnHwrlCupOtL1mhVZwsVYKR7ieJ0Q3oVMFbSTz3kjIKT6pTRXuYKhCJ 8g4TY2yZZfC+jPItQQ6xeVScYybU6QQ8M2mEi+9LveNhcsW3Sn5YmcbEVRpveWQnxSPx m/GPUwOZQNS+G9/Pt4r39zPqOeHca4D1a10USbMu7X0lKAHsMS1lQEtSStFa8nsg3QOi W1+9q+MuaoA5edKNVf0PSvLb1MGUVwT750NOVKHc7OQdBVwsCFpQiNEmUyzTwwaG+AHO JEPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=wIZiFEsZAeYnOqGs2+bUuvQH61Nh7FBJ6q0NJr//BIc=; b=AbAe2gMlTLj8UmLrrcTVEQQqUyDAXP5GofXwObE9zWi9ccbuex0jVxBw2ZPDYYikDR U7JKPkhBbrjxrq+1Bo+ZHq7G3Z8AN99etrRRBB3Z/I106FbTR4zw/9UsFrYDoqJwgvuf lBwdIvGD8GPzmmEhHFpZYXA3zssDxqybtp9SJJeNJqk9qFWHpTbM9NFtEp7EbDPCI4jI yfLyKkmTdDM2M0J+ci8GPmnGafDW2LGBckvny2HJFElsLLVDUIA3g4hKM3CnOmoTCHdu DCfa1g7PUoEUNC4R6poM4Qzj6dCyOspL1iqykmFjJeVYGmT8F4GLte45BTvLWAAnMviE jw+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=Jsqb8R27; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j8-20020a636e08000000b0037439d34a8esi14866482pgc.347.2022.03.14.00.59.14; Mon, 14 Mar 2022 00:59:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=Jsqb8R27; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232793AbiCMKsk (ORCPT + 99 others); Sun, 13 Mar 2022 06:48:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230260AbiCMKsh (ORCPT ); Sun, 13 Mar 2022 06:48:37 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22518114FC3; Sun, 13 Mar 2022 03:47:28 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 7B54922239; Sun, 13 Mar 2022 11:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1647168446; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wIZiFEsZAeYnOqGs2+bUuvQH61Nh7FBJ6q0NJr//BIc=; b=Jsqb8R27K4Qb9rhh2kkLgl4QF30L8Zoir/MEJOYpBLov6Da5zXRUtfV+p+nGRhKbvGTnwF 4Lb61D5TLrpwVDwpyDGWfpEDpMqzJDkq/3IQ2AZ2Lh/Uc0xSmioHscQLiXleTN7XG8PXKq Wb9AV4OIWFUGZw+ADvWBDNImlOWbAMk= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 13 Mar 2022 11:47:26 +0100 From: Michael Walle To: Krzysztof Kozlowski Cc: "David S . Miller" , Jakub Kicinski , Rob Herring , Andrew Lunn , Heiner Kallweit , Russell King , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible In-Reply-To: <08b89b3f-d0d3-e96f-d1c3-80e8dfd0798f@kernel.org> References: <20220313002536.13068-1-michael@walle.cc> <20220313002536.13068-2-michael@walle.cc> <08b89b3f-d0d3-e96f-d1c3-80e8dfd0798f@kernel.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Krzysztof, Am 2022-03-13 10:47, schrieb Krzysztof Kozlowski: > On 13/03/2022 01:25, Michael Walle wrote: >> The MDIO controller has support to release the internal PHYs from >> reset >> by specifying a second memory resource. This is different between the >> currently supported SparX-5 and the LAN966x. Add a new compatible to >> distiguish between these two. >> >> Signed-off-by: Michael Walle >> --- >> Documentation/devicetree/bindings/net/mscc-miim.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/net/mscc-miim.txt >> b/Documentation/devicetree/bindings/net/mscc-miim.txt >> index 7104679cf59d..a9efff252ca6 100644 >> --- a/Documentation/devicetree/bindings/net/mscc-miim.txt >> +++ b/Documentation/devicetree/bindings/net/mscc-miim.txt >> @@ -2,7 +2,7 @@ Microsemi MII Management Controller (MIIM) / MDIO >> ================================================= >> >> Properties: >> -- compatible: must be "mscc,ocelot-miim" >> +- compatible: must be "mscc,ocelot-miim" or "mscc,lan966x-miim" > > No wildcards, use one, specific compatible. I'm in a kind of dilemma here, have a look yourself: grep -r "lan966[28x]-" Documentation Should I deviate from the common "name" now? To make things worse, there was a similar request by Arnd [1]. But the solution feels like cheating ("lan966x" -> "lan966") ;) On a side note, I understand that there should be no wildcards, because the compatible should target one specific implementation, right? But then the codename "ocelot" represents a whole series of chips. Therefore, names for whole families shouldn't be used neither, right? -michael [1] https://lore.kernel.org/lkml/CAK8P3a2kRhCOoXnvcMyqS-zK2WDZjtUq4aqOzE5VV=VMg=pVOA@mail.gmail.com/