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 X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15279C433E0 for ; Wed, 13 Jan 2021 11:16:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C718123329 for ; Wed, 13 Jan 2021 11:16:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728185AbhAMLQZ (ORCPT ); Wed, 13 Jan 2021 06:16:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:42744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727285AbhAMLQZ (ORCPT ); Wed, 13 Jan 2021 06:16:25 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D6A4E233CE; Wed, 13 Jan 2021 11:15:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610536544; bh=+KwpHDNA1Aor+AsvBmM16YIXiznluriup/9muCgEAng=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OWJ1zjksTYle6TKbzWbRDcjrXmlGX67UVj6hkbpUsuYkg1zCb7wfCv0ozRfWOB13R P99UF6fYKS7vADXIYqQFK9aYN1A2zV4SL/wUGILJKyzCJsikuwf4ZxTAXLuntHKCeT WnwbUwzffMHWKl+a/Ge6OcHNlWB1NBSmY36jFLI0JAS9FIuCyTspLybae9hUSy6wgz foAnyrddn/1LZlpunSQugJIY5oVIf+35Ytps1oYZiHOwXykLezQIHTljAuS8Ia0Zpl XDZLei7bJyP2IlsKBYSiCjuIRrAzobi7UX/cKu2u1uodInwTg+IqXmtE3Z0ryqiEHW cHvpn+wGuVfpw== Received: by mail-oi1-f179.google.com with SMTP id f132so1642530oib.12; Wed, 13 Jan 2021 03:15:43 -0800 (PST) X-Gm-Message-State: AOAM530C9U+C5SsFonrQYEMLNDP4iz2OkPzyvqPQVSZF26UPbR0zeXYq k/YQhMhQyk5+xAwk74B0O6EOyyN6zg+Rclls/PI= X-Google-Smtp-Source: ABdhPJxZ8wAO+/r7uxZhfD8Ab3Us2Ubaf1q8ERA4r3pTc8QV3ZdPgcNQLLUPFFVLoZ9K1Xe8erI+J7UYLVuwzSn/b70= X-Received: by 2002:aca:e103:: with SMTP id y3mr798708oig.11.1610536542964; Wed, 13 Jan 2021 03:15:42 -0800 (PST) MIME-Version: 1.0 References: <20210112015602.497-1-thunder.leizhen@huawei.com> <20210112015602.497-3-thunder.leizhen@huawei.com> <82720d56-733d-28e9-b682-bcc769ad70ab@huawei.com> In-Reply-To: <82720d56-733d-28e9-b682-bcc769ad70ab@huawei.com> From: Arnd Bergmann Date: Wed, 13 Jan 2021 12:15:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller To: "Leizhen (ThunderTown)" Cc: devicetree , Arnd Bergmann , Greg Kroah-Hartman , Will Deacon , linux-kernel , Haojian Zhuang , Rob Herring , Wei Xu , Russell King , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown) wrote: > On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: > > On 2021/1/12 21:55, Arnd Bergmann wrote: > >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) > >> wrote: > >>> On 2021/1/12 16:46, Arnd Bergmann wrote: > >>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei wrote: > >>>> > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Hisilicon L3 cache controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Wei Xu > >>>>> + > >>>>> +description: | > >>>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical > >>>>> + addresses. The data cached in the L3 outer cache can be operated based on the > >>>>> + physical address range or the entire cache. > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + items: > >>>>> + - const: hisilicon,l3cache > >>>>> + > >>>> > >>>> The compatible string needs to be a little more specific, I'm sure > >>>> you cannot guarantee that this is the only L3 cache controller ever > >>>> designed in the past or future by HiSilicon. > >>>> > >>>> Normally when you have an IP block that is itself unnamed but that is specific > >>>> to one or a few SoCs but that has no na, the convention is to include the name > >>>> of the first SoC that contained it. > >>> > >>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" > >>> and "hisilicon,hi1215-l3cache". > > > > Sorry, Just received a response from the hardware developers, the SoC names need to > > be changed: > > hi1381 --> kunpeng509 > > hi1215 --> kunpeng506 > > > > So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 > > I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in > the future. Maybe the SoC name is changed later, and v2 is not required. I would prefer the more specific name to be listed as well. You can use the generic "hisilicon,kunpeng-l3cache" as the key that the driver uses, but please also include the chip specific one here. We tend to use the chip identifiers (hi1381, ...), but if the marketing names (kunpeng509, ...) are now what they are known as in the data sheet, then use that. The problem with marketing names is that they are more often unrelated to the technology underneath. It's possible that there might be e.g. kunpeng507 chip that sold to the same customers but very different internally from kunpeng506/kunpeng509. This also happens with the chip numbers, but those tend to be more stable (at least for other manufacturers). Arnd 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 X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B03C433E0 for ; Wed, 13 Jan 2021 11:17:48 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CC93F2333F for ; Wed, 13 Jan 2021 11:17:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC93F2333F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EliD2Z9M/pzM2T8TVEtSN+g6y/eJSOKq9E3MqhDtvc8=; b=xQ59NRO7RFpfzI5uqcqLlBLjd BGdSnE/b4jXy+I1YTuj3gb4zH3EgAhcqhYqSQThLUduA17PqKkB2y1c3vubxuhQaKbSy2jcBZBUkK xbNNJz1SxGL/8FVcPL0w2dnSKGAfMSGOY3KW9I8ameHRixTY0PgpptZzrZNZp3rHxGY6Ak33/t4nA AklTVkD/Sznd0qNKPAwTKqypDMuXxmncG3qfZSpetpd5ezqCSwSlUhBF1mf9fThuKkYTtjU5AZu21 LuUMr8Wol5gPvAe1gqo8hoWrI1WRYBX0qet3VxhVRDJDjEWWIlCxMKXXzgBZEPtCmkwnmNjNZI6vh oO4xxJzJg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kze7z-0007ku-2i; Wed, 13 Jan 2021 11:15:51 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kze7t-0007k5-3l for linux-arm-kernel@lists.infradead.org; Wed, 13 Jan 2021 11:15:49 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CD6392339F for ; Wed, 13 Jan 2021 11:15:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610536543; bh=+KwpHDNA1Aor+AsvBmM16YIXiznluriup/9muCgEAng=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HD4RWjjeVTTpc+TUexTJuZBQj4qWHn/RBD9jFKVd58EoL9d9NzavZSZhND+zEPitK JFpE5HLYcebB+X4IVl1xlpTNHOSioOydC7nTJEwjTd0uJNZdxmehlK5Ut7x3ehXdch 8MWs9/Jo31WAzRj+lELAljSiC5zOGfUNrXmAiGTclUn2saKVx3Ci9+nFFciw34M/L0 2zg5sTbmKB+Ju97I6SaXBfklzUzrA0y2oxOPzRdYBFDWC4cH6sQyYtIAzJ8PYgPjva W47Za+tkLv8wyiuoBX9nnI0CDrf37PeH0gAyAcUcpRA/pTIqBT7DFZ5ldhd/AR6hQs hZZTqy4q/nakQ== Received: by mail-oi1-f182.google.com with SMTP id d189so1654088oig.11 for ; Wed, 13 Jan 2021 03:15:43 -0800 (PST) X-Gm-Message-State: AOAM530ymqzkEowA34+/HMJRmXavVNMNHdRbT4EmwUfNckhCJPaMLQFo hExdh9ztBo38k8iUuWAw5qFudZprbrzoGJ30BgI= X-Google-Smtp-Source: ABdhPJxZ8wAO+/r7uxZhfD8Ab3Us2Ubaf1q8ERA4r3pTc8QV3ZdPgcNQLLUPFFVLoZ9K1Xe8erI+J7UYLVuwzSn/b70= X-Received: by 2002:aca:e103:: with SMTP id y3mr798708oig.11.1610536542964; Wed, 13 Jan 2021 03:15:42 -0800 (PST) MIME-Version: 1.0 References: <20210112015602.497-1-thunder.leizhen@huawei.com> <20210112015602.497-3-thunder.leizhen@huawei.com> <82720d56-733d-28e9-b682-bcc769ad70ab@huawei.com> In-Reply-To: <82720d56-733d-28e9-b682-bcc769ad70ab@huawei.com> From: Arnd Bergmann Date: Wed, 13 Jan 2021 12:15:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller To: "Leizhen (ThunderTown)" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210113_061545_353412_5223825E X-CRM114-Status: GOOD ( 22.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Arnd Bergmann , Greg Kroah-Hartman , Will Deacon , linux-kernel , Haojian Zhuang , Rob Herring , Wei Xu , Russell King , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown) wrote: > On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: > > On 2021/1/12 21:55, Arnd Bergmann wrote: > >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) > >> wrote: > >>> On 2021/1/12 16:46, Arnd Bergmann wrote: > >>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei wrote: > >>>> > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Hisilicon L3 cache controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Wei Xu > >>>>> + > >>>>> +description: | > >>>>> + The Hisilicon L3 outer cache controller supports a maximum of 36-bit physical > >>>>> + addresses. The data cached in the L3 outer cache can be operated based on the > >>>>> + physical address range or the entire cache. > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + items: > >>>>> + - const: hisilicon,l3cache > >>>>> + > >>>> > >>>> The compatible string needs to be a little more specific, I'm sure > >>>> you cannot guarantee that this is the only L3 cache controller ever > >>>> designed in the past or future by HiSilicon. > >>>> > >>>> Normally when you have an IP block that is itself unnamed but that is specific > >>>> to one or a few SoCs but that has no na, the convention is to include the name > >>>> of the first SoC that contained it. > >>> > >>> Right, thanks for your suggestion, I will rename it to "hisilicon,hi1381-l3cache" > >>> and "hisilicon,hi1215-l3cache". > > > > Sorry, Just received a response from the hardware developers, the SoC names need to > > be changed: > > hi1381 --> kunpeng509 > > hi1215 --> kunpeng506 > > > > So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng L3 > > I thought about it. Let's name it "hisilicon,kunpeng-l3cache", and then add v2 in > the future. Maybe the SoC name is changed later, and v2 is not required. I would prefer the more specific name to be listed as well. You can use the generic "hisilicon,kunpeng-l3cache" as the key that the driver uses, but please also include the chip specific one here. We tend to use the chip identifiers (hi1381, ...), but if the marketing names (kunpeng509, ...) are now what they are known as in the data sheet, then use that. The problem with marketing names is that they are more often unrelated to the technology underneath. It's possible that there might be e.g. kunpeng507 chip that sold to the same customers but very different internally from kunpeng506/kunpeng509. This also happens with the chip numbers, but those tend to be more stable (at least for other manufacturers). Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel