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: <ef3b8e12-0677-4e49-bf2c-b8136c9a6908@kernel.org>
Date: Wed, 6 Aug 2025 11:23:21 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Pankaj Dubey <pankaj.dubey@...sung.com>,
 'SeonGu Kang' <ksk4725@...sia.com>,
 'Jesper Nilsson' <jesper.nilsson@...s.com>,
 'Michael Turquette' <mturquette@...libre.com>,
 'Stephen Boyd' <sboyd@...nel.org>, 'Rob Herring' <robh@...nel.org>,
 'Krzysztof Kozlowski' <krzk+dt@...nel.org>,
 'Conor Dooley' <conor+dt@...nel.org>,
 'Sylwester Nawrocki' <s.nawrocki@...sung.com>,
 'Chanwoo Choi' <cw00.choi@...sung.com>,
 'Alim Akhtar' <alim.akhtar@...sung.com>,
 'Linus Walleij' <linus.walleij@...aro.org>,
 'Tomasz Figa' <tomasz.figa@...il.com>,
 'Catalin Marinas' <catalin.marinas@....com>, 'Will Deacon'
 <will@...nel.org>, 'Arnd Bergmann' <arnd@...db.de>
Cc: 'kenkim' <kenkim@...sia.com>, 'Jongshin Park' <pjsin865@...sia.com>,
 'GunWoo Kim' <gwk1013@...sia.com>, 'HaGyeong Kim' <hgkim05@...sia.com>,
 'GyoungBo Min' <mingyoungbo@...sia.com>, 'SungMin Park'
 <smn1196@...sia.com>, 'Shradha Todi' <shradha.t@...sung.com>,
 'Ravi Patel' <ravi.patel@...sung.com>, 'Inbaraj E' <inbaraj.e@...sung.com>,
 'Swathi K S' <swathi.ks@...sung.com>, 'Hrishikesh'
 <hrishikesh.d@...sung.com>, 'Dongjin Yang' <dj76.yang@...sung.com>,
 'Sang Min Kim' <hypmean.kim@...sung.com>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
 linux-arm-kernel@...s.com, linux-clk@...r.kernel.org,
 devicetree@...r.kernel.org, linux-gpio@...r.kernel.org, soc@...ts.linux.dev
Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC

On 06/08/2025 11:05, Pankaj Dubey wrote:
> 
>> Also SAME strict DT compliance profile will be applied. (see more on
>> that below)
>>
>>>
>>> Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe it's
>> reasonable
>>> to create a separate directory for it, similar to FSD.
>>
>> No. It was a mistake for FSD to keep it separate why? Because there is
>> no single non-Samsung stuff there. I am afraid exactly the same will
>> happen there.
>>
> 
> I am not sure, why you are saying this as a mistake, in case next version of FSD


My mistake that I agreed on that, based on promise that "there will be
non Samsung stuff" and that "non Samsung stuff" never happened.

> or ARTPEC is manufactured (ODM) by another vendor in that case, won't it
> create problems? 


No problems here. Non-Samsung Artpec/Axis soc will not go there. It will
go the top-level axis directory, just like artpec-6


> 
> For example ARTPEC-6/7 (ARM based) have their own directories as "arch/arm/boot/dts/axis/"
> These were not Samsung (ODM) manufactures SoCs. 
> 
> But ARTPEC-8/9 (ARM64) based SoCs are samsung manufactured. What if the next version say
> ARTPEC-10 is not samsung manufactured, so different version of products (SoCs) from
> same vendor (OEM), in this case Axis, will have code in separate directories and with different maintainers? 

It will be the same with Google Pixel for whatever they decide in the
future. dts/exynos/google/ + dts/google/.

I know that this is not ideal, but for me grouping samsung stuff
together is far more important, because there is much, much more to
share between two SoCs designed by Samsung, than Axis-9 and future
non-Samsung Axis-10. And I have `git grep` as argument:
git grep compatible -- arch/arm64/boot/dts/tesla/

and point me to any Tesla IP. Zero results.


> 
>> Based on above list of blocks this should be done like Google is done,
>> so it goes as subdirectory of samsung (exynos). Can be called axis or
>> artpec-8.
> 
> I will suggest to keep axis, knowing the fact that sooner after artpec-8 patches gets approved and merged
> we have plan to upstream artpec-9 (ARM64, Samsung manufactured) as well.
> 
>>
>> To clarify: Only this SoC, not others which are not Samsung.
>>
>>>
>>> We will remove Samsung and Coasia teams from the maintainers list in v2
>> and only
>>> Axis team will be maintainer.
>>
>> A bit unexpected or rather: just use names of people who WILL be
>> maintaining it. If this is Jesper and Lars, great. Just don't add
>> entries just because they are managers.
> 
> AFAIK, Jesper will be taking care. 
> 
>>
>>>
>>> Maintainer list for previous generation of Axis chips (ARM based) is already
>> present,
>>> so this will be merged into that.
>>
>> Existing Artpec entry does not have tree mentioned, so if you choose
>> above, you must not add the tree, since the tree is provided by Samsung SoC.
>>
> 
> OK
> 
>> OTOH, how are you going to add there strict DT compliance? Existing axis
>> is not following this, but artpec-8, as a Samsung derivative, MUST
>> FOLLOW strict DT compliance. And this should be clearly marked in
>> maintainer entry, just like everywhere else.
>>
> 
> As I said this is tricky situation, though artpec-8 is derivative of samsung, we can't confirm 
> if future versions (> 9) will be samsung derivative. 
> 
> But this would be case for all such custom ASIC manufactured by samsung, so I would like to
> understand how this will be handled? 


I suggest to do the same as Google and when I say Google in this email,
I mean Pixel/GS101. Google was easier because there was no prior entry
and Axis has, so you will have two Axis entries. But I don't see how we
can add clean-dts profiles to the existing Axis entry, if you decide to
include Artpec-8 in that one.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ