Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3080906pxp; Mon, 14 Mar 2022 10:24:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynQgNRT2IaFHuEf2WA3vYXb4c+ArvuIih4Xgh4KOuQ2QJ5ilHfWLeSGf39LIfbIsVTGfYK X-Received: by 2002:a17:903:230f:b0:151:e465:1877 with SMTP id d15-20020a170903230f00b00151e4651877mr24836224plh.19.1647278643201; Mon, 14 Mar 2022 10:24:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647278643; cv=none; d=google.com; s=arc-20160816; b=rCn3n8pC+V13jnlhTu2xkz3BoN/3YB0zQwuAKyZzyQZIL34NsgkdV5HOdDBMGhbXx+ dUnKD9fNOkyHd1IhDtLpTvf383skAEBO/rGZmDlbGOFYiFrtPdZwcckuWWJAgjIduUN7 I5JOJrOZTLo6BnPey4RxD/qk4i37o01GlUGU6Rq0nk96Cea8nt/2rEk9LSRn2ktjpROr 9YeexKNBNnXwxbx7ls5AnLkzMyd2QUF98foA7tslEYMSAwoRWr8UDm7qrSO0Aq/QdBI1 43xYHuGqLJA4tjwKUA7iU8SBySICa8v1X5z4COeXCcq9v/uKmwAjel5r+jWR3a5OSKhQ n6DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:content-language:subject:from:user-agent:mime-version:date :message-id; bh=u8bQocCu7+BWd2wXu/r5WL7YQLXrKPOJ0zyslcPG8rg=; b=dx4EpdO4dH3OVf+aSKwjMHU3v2+GyKhZFkYV9GcLb5IuFt6CEVPIYrbQns1g6hAe2x YCke2UEFotr3PTmz7Z1JYJtFue9tyRNT7P6CSbDnWvLklzExLstOEPtJzRR+9n44y5yp ocy+3Cc4DH3GxzLuRicgyUBxtTOYK4a7MiSZ8qlSlAUd9Ixcibnh/UMbqCsOzFzsWSCb nMKOxdAzwibsqr2rXY47djE8K/dueoG75Zyexf68UFd43sd3369zDlpgz3SnEmYWlV5w hmZnSKMnbR1tJ+w5+G0eA1tqoGkLODXHPsZqurgCM90so06YS/ampx6WRbW8hHtZ1Pfx O3dg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a056a000a8c00b004ce5f673049si16252778pfl.229.2022.03.14.10.23.49; Mon, 14 Mar 2022 10:24:03 -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; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234976AbiCMQLP (ORCPT + 99 others); Sun, 13 Mar 2022 12:11:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbiCMQLN (ORCPT ); Sun, 13 Mar 2022 12:11:13 -0400 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75D7626564; Sun, 13 Mar 2022 09:10:05 -0700 (PDT) Received: by mail-ed1-f47.google.com with SMTP id t1so16498225edc.3; Sun, 13 Mar 2022 09:10:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:content-language:to:cc:references:in-reply-to :content-transfer-encoding; bh=u8bQocCu7+BWd2wXu/r5WL7YQLXrKPOJ0zyslcPG8rg=; b=RBSOCQKoZXiub3rmTcCWiDkoZA7YoOdiCV9DVh1rRwPdSryCJAtIkANZHEDOJS872E sHXFRYGpoHS8SLE0rm39QPdOLK5tWG93zCXtxxhITSjHM9x06TLVdyMGxOH3yHX4kCwE 5vDbHuaZ18MmskpwYx2hIl/NXvmKtLR0DU0RhAy/ZgNrtxN/7jg2B5FYGhk8iMKc55GO n8RckuJxhvbLwnQebowE4X94vp3htcyEBoMmZBm5PUzFi0vO+iWSmT64pzhJxwWqJDKe 5NQBjltufOCSOFkn22tXy1QlwQuSwavUtTjdCkMyBaOAaKgNc45E6xWW8R3jTKARiv6Q AHzA== X-Gm-Message-State: AOAM531PgPvaZ939/7I+eSZSM4bk1scAtEZ0Qm4rVxy5DvIXo+UAEU/Q DEQ26smb5VayStnIIa40OP5GnlAEWKM= X-Received: by 2002:a50:d550:0:b0:416:2ac8:b98e with SMTP id f16-20020a50d550000000b004162ac8b98emr17167215edj.236.1647187803964; Sun, 13 Mar 2022 09:10:03 -0700 (PDT) Received: from [192.168.0.152] (xdsl-188-155-174-239.adslplus.ch. [188.155.174.239]) by smtp.googlemail.com with ESMTPSA id i6-20020a17090685c600b006daecf0b350sm5689279ejy.75.2022.03.13.09.10.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Mar 2022 09:10:03 -0700 (PDT) Message-ID: <2d35127c-d4ef-6644-289a-5c10bcbbbf84@kernel.org> Date: Sun, 13 Mar 2022 17:10:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 From: Krzysztof Kozlowski Subject: Re: [PATCH net-next v2 1/3] dt-bindings: net: mscc-miim: add lan966x compatible Content-Language: en-US To: Michael Walle 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 References: <20220313002536.13068-1-michael@walle.cc> <20220313002536.13068-2-michael@walle.cc> <08b89b3f-d0d3-e96f-d1c3-80e8dfd0798f@kernel.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 On 13/03/2022 11:47, Michael Walle wrote: > 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. Typo here, BTW. >>> >>> 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") ;) The previous 966x cases were added by one person from Microchip, so he actually might know something. But do you know whether lan966x will cover all current and future designs from Microchip? E.g. lan9669 (if ever made) will be the same? Avoiding wildcard is the easiest, just choose one implementation, e.g. "lan9662". Different topic is that all current lan966[28] are from Microchip and you still add Microsemi, even though it was acquired by Microchip. That's an inconsistency which should be rather fixed. > > 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? You're not adding "ocelot" now, so it is separate topic. However a compatible like "mscc,ocelot" feels wrong, unless it is used as a fallback (see: git grep 'apple,'). Best regards, Krzysztof