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: <013301dc0768$6f58dc40$4e0a94c0$@samsung.com>
Date: Thu, 7 Aug 2025 12:26:27 +0530
From: "Pankaj Dubey" <pankaj.dubey@...sung.com>
To: "'Krzysztof Kozlowski'" <krzk@...nel.org>, "'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

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

I am not authorized to comment on FSD's non Samsung stuff at this moment.
But I got your point.

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

Okay, understood. I assume Axis team will be fine with this approach.
Let me align with them internally and address all the review comments in v2. 

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

Okay we will have separate dts profile aligned with Exynos DT compliance for
ARM64 based Axis SoCs which are manufactured by Samsung at this moment. 

> 
> Best regards,
> Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ