linux-kernel - Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC

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: <9b98fd89-87b5-5026-fb0c-16bb956801ea@canonical.com>
Date:   Mon, 17 Jan 2022 16:00:44 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Alim Akhtar <alim.akhtar@...sung.com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        SoC Team <soc@...nel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Olof Johansson <olof@...om.net>,
        Linus Walleij <linus.walleij@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@...r.kernel.org>,
        Pankaj Dubey <pankaj.dubey@...sung.com>, linux-fsd@...la.com
Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC

On 17/01/2022 15:14, Arnd Bergmann wrote:
> On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <alim.akhtar@...sung.com> wrote:
>>
>>> I cannot judge how different this is from Exynos subarchitecture - looking at
>>> patches it is not different - so I could understand a FSD sub-arch with only one
>>> SoC.
>>>
>> I understand, it is a bit difficult to visualize it with the current patch set.
>> As discuss on the other thread, FSD is different, more over the vendor is different, internal design is different.
> 
> Is it based on another SoC design then? Most new SoCs are derived from
> some other
> one, so it makes sense to put it into the same family. E.g. the Apple
> M1 takes bits from
> both Exynos and PA-Semi SoCs but has more newly added components than
> either one.

It seems Apple M1 shares only few bits with SoC. I am aware of only UART
driver as directly re-usable.

> 
> I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation

Plus: UART, watchdog, PWM, I2C, I2S, USB PHY, DWC3 USB (in Exynos
flavor), UFS (also in Exynos-looking flavor), MFC (video codec), some
similarities in DW PCIe, TMU (thermal). Looking at DTS there are
differences but just few comparing to most of shared blocks.

Additionally SoC BSP (and maybe SoC itself...) was actually developed or
co-developed by Samsung, judging by copyrights in the BSP code. Even the
original DTSI has:

	TURBO TRAV SoC device tree source
	Copyright (c) 2017 Samsung Electronics Co., Ltd.

Tesla could still customize it a lot, but it is a strong hint that most
of it came from Samsung LSI and shares with existing Samsung designs.

Have in mind that recent Exynos chips are significantly different than
early ARMv7 or ARMv8 designs and we still consider them part of Exynos
family.

> with Exynos, we should consider it part of the Exynos family,
> regardless of what other
> blocks may exist next to those.

Yes. I don't see the benefit of keeping it outside of Exynos. It will
sprinkle "depends on ARCH_EXYNOS || ARCH_FSD" all over (or depend on
Exynos like you suggested).

Best regards,
Krzysztof