linux-kernel - Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 13 Jan 2021 20:33:46 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     devicetree <devicetree@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Haojian Zhuang" <haojian.zhuang@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Wei Xu <xuwei5@...ilicon.com>,
        Russell King <rmk+kernel@....linux.org.uk>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3
 cache controller



On 2021/1/13 19:15, Arnd Bergmann wrote:
> On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown)
> <thunder.leizhen@...wei.com> 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)
>>>> <thunder.leizhen@...wei.com> wrote:
>>>>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>>>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei <thunder.leizhen@...wei.com> 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 <xuwei5@...ilicon.com>
>>>>>>> +
>>>>>>> +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.

Oh, yes. Sometimes, the "syscon" is used this way . The first string describes
the component information，and the second string is used to match the driver.

compatible = "hisilicon,kunpeng506-l3cache", "hisilicon,kunpeng-l3cache"


> We tend to use the chip identifiers
> (hi1381, ...), but if
> the marketing names (kunpeng509, ...) are now what they are known as in the

The hardware developers told me that hi1381 is the internal chip identifier,
and should be deprecated. kunpeng509 is both chip identifier and marketing name.

Kunpeng is the pinyin of two Chinese characters. They are two mythical animals.

> 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,

It shouldn't make a big difference，unless the first two numbers are different.

> but those tend to be more stable (at least for other manufacturers).
> 
>        Arnd
> 
> .
>