From: Olof Johansson <olof@lixom.net> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Arnd Bergmann <arnd@arndb.de>, Alim Akhtar <alim.akhtar@samsung.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, SoC Team <soc@kernel.org>, linux-clk <linux-clk@vger.kernel.org>, DTML <devicetree@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Rob Herring <robh+dt@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Pankaj Dubey <pankaj.dubey@samsung.com>, linux-fsd@tesla.com Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC Date: Mon, 17 Jan 2022 12:41:11 -0800 [thread overview] Message-ID: <CAOesGMi8EBFGGj7sQsPZfDh=AhpPCBYFazb9yRYdEVX=MO7tog@mail.gmail.com> (raw) In-Reply-To: <9b98fd89-87b5-5026-fb0c-16bb956801ea@canonical.com> On Mon, Jan 17, 2022 at 7:00 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > > On 17/01/2022 15:14, Arnd Bergmann wrote: > > On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <alim.akhtar@samsung.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. I think it's a misnomer to call SoCs like these "based on each other". What often happens is that a manufacturer reuses IPs between designs since they're there, they're available and they work and there's little reason to redo it, etc. For cases such as a vendor building a custom SoC for a specific customer (which, from the looks of this patchset seems to be the case -- this is not something I say with insider information :-), it makes sense to reuse IP blocks in the same way. It's actually a competitive benefit of the vendor to have silicon-proven IPs in this manner. Does this mean that this custom-built product is a part of a product family? I don't think that's the primary conclusion I would make -- it's more complex than that. And it also doesn't make all that much of a difference whether it's considered a family member or not. I would be very surprised if this SoC had a Samsung marketing name, since to my knowledge it's not sold to any other customer. If all we're arguing here about is a toplevel compatible and a Kconfig variable, then I don't see a need to spend a whole lot of time on this -- as long as it's not a change that ends up proliferating the whole source tree. I.e. if you want to create a new sub-arch, make sure it selects or depends on EXYNOS so you don't need to sprinkle a lot of "EXYNOS" -> "EXYNOS || TESLA" edits in the tree (as per below in the email). Same with the DT bindings. Can you just augment to make the tesla vendor prefix an allowed one for the exynos bindings where it makes sense? Toplevel board (and SoC) compats can of course still be independent. > 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). Depend or select (but select is a slippery slope so might be better avoided) seems like a pretty good option here to me. -Olof
WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Arnd Bergmann <arnd@arndb.de>, Alim Akhtar <alim.akhtar@samsung.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, SoC Team <soc@kernel.org>, linux-clk <linux-clk@vger.kernel.org>, DTML <devicetree@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Catalin Marinas <catalin.marinas@arm.com>, Rob Herring <robh+dt@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Pankaj Dubey <pankaj.dubey@samsung.com>, linux-fsd@tesla.com Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC Date: Mon, 17 Jan 2022 12:41:11 -0800 [thread overview] Message-ID: <CAOesGMi8EBFGGj7sQsPZfDh=AhpPCBYFazb9yRYdEVX=MO7tog@mail.gmail.com> (raw) In-Reply-To: <9b98fd89-87b5-5026-fb0c-16bb956801ea@canonical.com> On Mon, Jan 17, 2022 at 7:00 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > > On 17/01/2022 15:14, Arnd Bergmann wrote: > > On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <alim.akhtar@samsung.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. I think it's a misnomer to call SoCs like these "based on each other". What often happens is that a manufacturer reuses IPs between designs since they're there, they're available and they work and there's little reason to redo it, etc. For cases such as a vendor building a custom SoC for a specific customer (which, from the looks of this patchset seems to be the case -- this is not something I say with insider information :-), it makes sense to reuse IP blocks in the same way. It's actually a competitive benefit of the vendor to have silicon-proven IPs in this manner. Does this mean that this custom-built product is a part of a product family? I don't think that's the primary conclusion I would make -- it's more complex than that. And it also doesn't make all that much of a difference whether it's considered a family member or not. I would be very surprised if this SoC had a Samsung marketing name, since to my knowledge it's not sold to any other customer. If all we're arguing here about is a toplevel compatible and a Kconfig variable, then I don't see a need to spend a whole lot of time on this -- as long as it's not a change that ends up proliferating the whole source tree. I.e. if you want to create a new sub-arch, make sure it selects or depends on EXYNOS so you don't need to sprinkle a lot of "EXYNOS" -> "EXYNOS || TESLA" edits in the tree (as per below in the email). Same with the DT bindings. Can you just augment to make the tesla vendor prefix an allowed one for the exynos bindings where it makes sense? Toplevel board (and SoC) compats can of course still be independent. > 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). Depend or select (but select is a slippery slope so might be better avoided) seems like a pretty good option here to me. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-17 20:41 UTC|newest] Thread overview: 159+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20220113122302epcas5p1d45c0714fe286f8f91d0f28c3fad86e4@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 00/23] Add support for Tesla Full Self-Driving (FSD) SoC Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122311epcas5p4b7c253b49dce3bd3580407fcf312e70e@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 01/23] dt-bindings: clock: Document FSD CMU bindings Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:40 ` Krzysztof Kozlowski 2022-01-13 12:40 ` Krzysztof Kozlowski 2022-01-14 5:48 ` Alim Akhtar 2022-01-14 5:48 ` Alim Akhtar 2022-01-13 23:33 ` Rob Herring 2022-01-13 23:33 ` Rob Herring [not found] ` <CGME20220113122317epcas5p11937078e2701b319a13b29e044224ec0@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 02/23] dt-bindings: clock: Add bindings definitions for FSD CMU blocks Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122324epcas5p105c53b448b5801813a02a88c6107a2f3@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 03/23] clk: samsung: fsd: Add initial clock support Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:49 ` Krzysztof Kozlowski 2022-01-13 12:49 ` Krzysztof Kozlowski 2022-01-14 6:16 ` Alim Akhtar 2022-01-14 6:16 ` Alim Akhtar [not found] ` <CGME20220113122330epcas5p46ae5cd30950b1d9126479231dcf5da49@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 04/23] clk: samsung: fsd: Add cmu_peric block clock information Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:55 ` Krzysztof Kozlowski 2022-01-13 12:55 ` Krzysztof Kozlowski 2022-01-14 6:30 ` Alim Akhtar 2022-01-14 6:30 ` Alim Akhtar [not found] ` <CGME20220113122334epcas5p2d5958c77b0635e848f81ed2c5c98cdd5@epcas5p2.samsung.com> 2022-01-13 12:11 ` [PATCH 05/23] clk: samsung: fsd: Add cmu_fsys0 " Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122338epcas5p17ad3a31077b98388c0a6779904ee651e@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 06/23] clk: samsung: fsd: Add cmu_fsys1 " Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122343epcas5p23831143e4e8fb92be8ad362f4817c03b@epcas5p2.samsung.com> 2022-01-13 12:11 ` [PATCH 07/23] clk: samsung: fsd: Add cmu_imem block " Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122346epcas5p41a7d6712c07544e99795ef5465f1f106@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 08/23] clk: samsung: fsd: Add cmu_mfc " Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122351epcas5p45f49a559af9f6d0c6ba573594f95561d@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 09/23] clk: samsung: fsd: Add cam_csi " Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122354epcas5p19e5cebe9e85e9ba1758fa0b9d7d1ef75@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 10/23] dt-bindings: pinctrl: samsung: Add compatible for Tesla FSD SoC Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:27 ` Krzysztof Kozlowski 2022-01-13 12:27 ` Krzysztof Kozlowski 2022-01-14 5:44 ` Alim Akhtar 2022-01-14 5:44 ` Alim Akhtar 2022-01-14 7:49 ` Krzysztof Kozlowski 2022-01-14 7:49 ` Krzysztof Kozlowski 2022-01-14 8:38 ` Alim Akhtar 2022-01-14 8:38 ` Alim Akhtar [not found] ` <CGME20220113122400epcas5p34363ba8f477b4c273d601d0b64324afa@epcas5p3.samsung.com> 2022-01-13 12:11 ` [PATCH 11/23] pinctrl: samsung: add FSD SoC specific data Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:57 ` Krzysztof Kozlowski 2022-01-13 12:57 ` Krzysztof Kozlowski 2022-01-16 12:05 ` Linus Walleij 2022-01-16 12:05 ` Linus Walleij [not found] ` <CGME20220113122404epcas5p4aa1c3ac09510eb55cce5fdd0791993a6@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 12/23] dt-bindings: add vendor prefix for Tesla Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:58 ` Krzysztof Kozlowski 2022-01-13 12:58 ` Krzysztof Kozlowski 2022-01-14 7:10 ` Alim Akhtar 2022-01-14 7:10 ` Alim Akhtar 2022-01-16 12:09 ` Linus Walleij 2022-01-16 12:09 ` Linus Walleij [not found] ` <CGME20220113122408epcas5p45053d1bf0acf2d8233a98b6c1abab6eb@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:33 ` Krzysztof Kozlowski 2022-01-13 12:33 ` Krzysztof Kozlowski 2022-01-14 16:57 ` Alim Akhtar 2022-01-14 16:57 ` Alim Akhtar 2022-01-14 17:29 ` Krzysztof Kozlowski 2022-01-14 17:29 ` Krzysztof Kozlowski 2022-01-17 13:26 ` Alim Akhtar 2022-01-17 13:26 ` Alim Akhtar 2022-01-17 14:14 ` Arnd Bergmann 2022-01-17 14:14 ` Arnd Bergmann 2022-01-17 15:00 ` Krzysztof Kozlowski 2022-01-17 15:00 ` Krzysztof Kozlowski 2022-01-17 20:41 ` Olof Johansson [this message] 2022-01-17 20:41 ` Olof Johansson [not found] ` <CGME20220113122413epcas5p46cb2cafb73936c423017240f98f72845@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 14/23] arm64: dts: fsd: Add initial device tree support Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:16 ` Krzysztof Kozlowski 2022-01-13 13:16 ` Krzysztof Kozlowski 2022-01-13 14:23 ` Arnd Bergmann 2022-01-13 14:23 ` Arnd Bergmann 2022-01-14 8:13 ` Alim Akhtar 2022-01-14 8:13 ` Alim Akhtar 2022-01-14 2:08 ` kernel test robot 2022-01-14 2:08 ` kernel test robot 2022-01-14 2:08 ` kernel test robot 2022-01-14 2:45 ` Rob Herring 2022-01-14 2:45 ` Rob Herring 2022-01-15 15:31 ` Alim Akhtar 2022-01-15 15:31 ` Alim Akhtar [not found] ` <CGME20220113122417epcas5p47398a5190cdf4c574c6f1762918b549f@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 15/23] arm64: dts: fsd: Add initial pinctrl support Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:19 ` Krzysztof Kozlowski 2022-01-13 13:19 ` Krzysztof Kozlowski 2022-01-17 13:44 ` Alim Akhtar 2022-01-17 13:44 ` Alim Akhtar 2022-01-17 13:50 ` Krzysztof Kozlowski 2022-01-17 13:50 ` Krzysztof Kozlowski 2022-01-18 14:58 ` Alim Akhtar 2022-01-18 14:58 ` Alim Akhtar [not found] ` <CGME20220113122421epcas5p1af8422fc992801ced57e0439b48ad08e@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 16/23] arm64: defconfig: Enable Tesla FSD SoC Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar [not found] ` <CGME20220113122427epcas5p1885d8b3b735e8f127b6694a309796e5a@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 17/23] Documentation: bindings: Add fsd spi compatible in dt-bindings document Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:21 ` Krzysztof Kozlowski 2022-01-13 13:21 ` Krzysztof Kozlowski 2022-01-13 13:24 ` Krzysztof Kozlowski 2022-01-13 13:24 ` Krzysztof Kozlowski 2022-01-14 7:17 ` Alim Akhtar 2022-01-14 7:17 ` Alim Akhtar [not found] ` <CGME20220113122435epcas5p18e6a2699f193b9e1287588278a570235@epcas5p1.samsung.com> 2022-01-13 12:11 ` [PATCH 18/23] spi: s3c64xx: Add spi port configuration for Tesla FSD SoC Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 12:59 ` Mark Brown 2022-01-13 12:59 ` Mark Brown 2022-01-14 7:15 ` Alim Akhtar 2022-01-14 7:15 ` Alim Akhtar 2022-01-13 13:28 ` Krzysztof Kozlowski 2022-01-13 13:28 ` Krzysztof Kozlowski 2022-01-16 12:12 ` Linus Walleij 2022-01-16 12:12 ` Linus Walleij [not found] ` <CGME20220113122440epcas5p4651d7cb2fc6d6a70fd5eaab5eadcf996@epcas5p4.samsung.com> 2022-01-13 12:11 ` [PATCH 19/23] arm64: dts: fsd: Add SPI device nodes Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:30 ` Krzysztof Kozlowski 2022-01-13 13:30 ` Krzysztof Kozlowski [not found] ` <CGME20220113122447epcas5p266d44c8df143229d22dfa700c285a786@epcas5p2.samsung.com> 2022-01-13 12:11 ` [PATCH 20/23] dt-bindings: iio: adc: exynos-adc: Add ADC-V3 variant Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:32 ` Krzysztof Kozlowski 2022-01-13 13:32 ` Krzysztof Kozlowski 2022-01-17 9:47 ` Jonathan Cameron 2022-01-17 9:47 ` Jonathan Cameron 2022-01-17 12:42 ` Alim Akhtar 2022-01-17 12:42 ` Alim Akhtar [not found] ` <CGME20220113122452epcas5p201a3a87d0e9c0e9f449a90ed62de1f1c@epcas5p2.samsung.com> 2022-01-13 12:11 ` [PATCH 21/23] iio: adc: exynos-adc: Add support for ADC V3 controller Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-16 11:19 ` Jonathan Cameron 2022-01-16 11:19 ` Jonathan Cameron 2022-01-17 12:20 ` Alim Akhtar 2022-01-17 12:20 ` Alim Akhtar [not found] ` <CGME20220113122456epcas5p35f6406ab03af58d2e56b0b7304d4d002@epcas5p3.samsung.com> 2022-01-13 12:11 ` [PATCH 22/23] arm64: dts: fsd: Add ADC device tree node Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:33 ` Krzysztof Kozlowski 2022-01-13 13:33 ` Krzysztof Kozlowski [not found] ` <CGME20220113122502epcas5p37747b0c5c242c0571d294b9245963a1c@epcas5p3.samsung.com> 2022-01-13 12:11 ` [PATCH 23/23] clocksource: exynos_mct: Add support for handling three clusters Alim Akhtar 2022-01-13 12:11 ` Alim Akhtar 2022-01-13 13:36 ` Krzysztof Kozlowski 2022-01-13 13:36 ` Krzysztof Kozlowski 2022-01-13 12:31 ` [PATCH 00/23] Add support for Tesla Full Self-Driving (FSD) SoC Krzysztof Kozlowski 2022-01-13 12:31 ` Krzysztof Kozlowski 2022-01-13 18:53 ` Olof Johansson 2022-01-13 18:53 ` Olof Johansson 2022-01-14 5:41 ` Alim Akhtar 2022-01-14 5:41 ` Alim Akhtar 2022-01-14 7:34 ` Krzysztof Kozlowski 2022-01-14 7:34 ` Krzysztof Kozlowski 2022-01-16 9:23 ` Pavel Machek 2022-01-16 9:23 ` Pavel Machek 2022-01-17 20:53 ` Olof Johansson 2022-01-17 20:53 ` Olof Johansson 2022-01-17 23:10 ` Pavel Machek 2022-01-17 23:10 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAOesGMi8EBFGGj7sQsPZfDh=AhpPCBYFazb9yRYdEVX=MO7tog@mail.gmail.com' \ --to=olof@lixom.net \ --cc=alim.akhtar@samsung.com \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=krzysztof.kozlowski@canonical.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-fsd@tesla.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=pankaj.dubey@samsung.com \ --cc=robh+dt@kernel.org \ --cc=s.nawrocki@samsung.com \ --cc=soc@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.