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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f013e9a1-81cd-14ed-0126-6edaee3a73fc@linaro.org>
Date:   Tue, 16 May 2023 13:42:05 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Bharat Bhushan <bbhushan2@...vell.com>,
        "wim@...ux-watchdog.org" <wim@...ux-watchdog.org>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXT] Re: [PATCH 1/2 v7] dt-bindings: watchdog: marvell GTI
 system watchdog driver

On 16/05/2023 13:24, Sunil Kovvuri Goutham wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> Sent: Tuesday, May 16, 2023 3:55 PM
>> To: Sunil Kovvuri Goutham <sgoutham@...vell.com>; Bharat Bhushan
>> <bbhushan2@...vell.com>; wim@...ux-watchdog.org; linux@...ck-us.net;
>> robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org; linux-
>> watchdog@...r.kernel.org; devicetree@...r.kernel.org; linux-
>> kernel@...r.kernel.org
>> Subject: Re: [EXT] Re: [PATCH 1/2 v7] dt-bindings: watchdog: marvell GTI system
>> watchdog driver
>>
>> On 16/05/2023 12:06, Sunil Kovvuri Goutham wrote:
>>
>>
>>>>>>> Marvell have octeontx2 series of processor which have watchdog timer.
>>>>>>> In 95xx,98xx,96xx are the processors in octeontx2 series of
>>>>>>> processor. So
>>>>>> octeontx2-95xx is on soc, octeontx2-96xx is another and so on.
>>>>>>
>>>>>> No, 95xx is not a processor. Otherwise please point me to exact
>>>>>> product datasheet. Hint: I checked it.
>>>>>
>>>>> Looks like 95xx data sheet is not public, will remove in that case.
>>>>
>>>> We can talk about 96xx. Can you point me to the SoC named exactly like this?
>>>> Hint: I checked it.
>>>
>>> To recap what Bharat mentioned before along with references to individual
>> processors.
>>> OcteonTx2 is a family of processors
>>> https://www.marvell.com/products/data-processing-units.html
>>> Please check for "OCTEON TX2 DPUs"
>>> CN96xx and CN98xx are two silicon variants in this family.
>>> https://www.marvell.com/content/dam/marvell/en/public-collateral/embed
>>> ded-processors/marvell-infrastructure-processors-octeon-tx2-cn92xx-cn9
>>> 6xx-cn98xx-product-brief-2020-02.pdf
>>
>> This is a product brief which further suggests CN96xx is a family (or sub-family).
>>
>> "xx" is pretty often used as family, not as product. Otherwise how one product
>> CN92XX can come with 12-18 cores *in the same time*?
> 
> "xx" here suggests skews, some 92xx may have 18 cores and some may have
> few cores fused out resulting in 12cores.

Is the DTSI for them the same? IOW, 12-core and 18-core SoCs have
exactly the same DTSI with all properties being the same, valid and not
customized by firmware per skew? If we talk about ARM architecture, DTS
expects CPUs there, so I really wonder how do you write one DTS which
has in the same time 12 and 18 enabled CPUs. Remember - the same time
and not changed by firmware.

> 
>>
>>>
>>> Since the HW block is same in all the variants of silicons in this
>>> family, we would like to use a generic string instead of different
>>> compatible string for each one. ie
>>> - const: marvell,octeontx2-wdt
>>> Hope this is okay.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__elixir.bootlin.com_linux_v6.1-
>> 2Drc1_source_Documentation_devicetree_bindings_writing-2Dbindings.rst-
>> 23L42&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=q3VKxXQKiboRw_F01ggTz
>> HuhwawxR1P9_tMCN2FODU4&m=GGfz5QI8ldHRqao5OsrfuHZQso5LLNBeBxCZr
>> Ai7Zow-
>> qoKl_S1Yw90OWnSZ3FFx&s=kM0VFY1b15BYvp2EUapQjZ6Eb96aZ_yAE76EKCmA
>> aEQ&e=
>>
>>>
>>> Same with CN10K or Octeon10 family of silicons.
>>> https://www.marvell.com/products/data-processing-units.html
>>> Please check for "OCTEON 10"
>>>
>>> CN103xx and CN106xx are two silicons in this family.
>>
>> Are they? "Up to 8" cores, so how this can be one specific silicon? One customer
>> buys CN10300 with 8 cores, second buys exactly the same CN10300 and has 4
>> cores?
>>
>> You are mixing families and specific devices.
> 
> I was making it simple to understand.
> 
> OcteonTx2 and Octeon10 (CN10K) are two generations of Octeon processors from Marvell.

I know. I don't think we talk about the same thing...

> Within each generation there are multiple silicon variants.
> Again for each variant there are multiple skews.
> 
> Since the watchdog hardware block functionality is same across all of above
> generations / variants / families / skews, is it okay to use below compatible strings ?

You got the link which explains it.

We had this discussions for thousands times. Just a few references from
bookmarks:

https://lore.kernel.org/all/20220822181701.GA89665-robh@kernel.org/
https://lore.kernel.org/all/78651e07-6b3e-4243-8e1f-fcd1dfb3ffe1@www.fastmail.com/
https://lore.kernel.org/all/288f56ba9cfad46354203b7698babe91@walle.cc/
https://lore.kernel.org/all/106e443a-e765-51fe-b556-e4e7e2aa771c@linaro.org/

Explain me how is this different. Please do not repeat the same
arguments as everywhere else, because we covered them.

> 
> - const: marvell,octeontx2-wdt
> - const: marvell,cn10k-wdt
> 
> Also this is the same naming we have been using in other drivers as well.
> drivers/net/ethernet/marvell/octeontx2
> drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c

Ah, the argument "others did it" or "in the past we did". If the
approach is buggy, does it mean you should duplicate the same buggy
approach to new bindings?

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ