Re: [RFC 00/10] ARM: Remove support for Exynos5440
On Tue, Apr 24, 2018 at 10:56 PM, Krzysztof Kozlowski wrote: > On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: >> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski >> wrote: > The only dependency is through Kconfig symbol (SOC_EXYNOS5440). After > applying 10/10, which removes SOC_EXYNOS5440, some automatic code > testers can complain about non-existing Kconfig option. That's not big > issue because all this will go away so indeed we could take everything > in one release. Right, I wouldn't worry about that. Kbuild itself doesn't warn about missing symbols, so this is only for helpful automated checks that tell us that there is still some pending work. Arnd
Re: [RFC 00/10] ARM: Remove support for Exynos5440
On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: > On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > > Hi, > > > > > > Overview > > > > Let's continue the removal of old platforms. We already get rid of > > Exynos4212. > > Now it's time for Exynos5440. > > > > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting > > server platforms but it did not make it to the market really. There are > > no development boards with it and probably there are no real products > > neither. The development for Exynos5440 ended in 2013 and since then > > the platform is in maintenance mode. > > > > The only development happening around it is the PCIe driver for Exynos5433 > > (ARMv8). [1] > > > > Removing Exynos5440, makes our life slightly easier: > > 1. Less maintenance, > > 2. Smaller code, less quirks, > > 3. No need to preserve (imaginary) backward-compatibility for Exynos PCIe > >driver (so it is easier to add support for Exynos5433). > > > > > > Because of point (3) above - I left the PCIe and PCIe PHY drivers intact. > > > > > > Dependencies > > > > I think about starting with removal of DTS in some kernel release (patch > > 1/10). > > Then all drivers can be removed/updated - subsystem maintainers can pick > > their > > patches freely. > > > > Finally, after getting rid of all Exynos5440 symbols, the last patch > > (10/10) will > > end in arm-soc tree. > > > > > > Any comments? > > I don't see any hard dependency here, if this is all unused, I think we > can apply both patches 1 and 10 into arm-soc at the same time as merging > the other patches through the respective subsystem trees. The only dependency is through Kconfig symbol (SOC_EXYNOS5440). After applying 10/10, which removes SOC_EXYNOS5440, some automatic code testers can complain about non-existing Kconfig option. That's not big issue because all this will go away so indeed we could take everything in one release. Best regards, rzysztof
Re: [RFC 00/10] ARM: Remove support for Exynos5440
On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > Hi, > > > Overview > > Let's continue the removal of old platforms. We already get rid of Exynos4212. > Now it's time for Exynos5440. > > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting > server platforms but it did not make it to the market really. There are > no development boards with it and probably there are no real products > neither. The development for Exynos5440 ended in 2013 and since then > the platform is in maintenance mode. > > The only development happening around it is the PCIe driver for Exynos5433 > (ARMv8). [1] > > Removing Exynos5440, makes our life slightly easier: > 1. Less maintenance, > 2. Smaller code, less quirks, > 3. No need to preserve (imaginary) backward-compatibility for Exynos PCIe >driver (so it is easier to add support for Exynos5433). > > > Because of point (3) above - I left the PCIe and PCIe PHY drivers intact. > > > Dependencies > > I think about starting with removal of DTS in some kernel release (patch > 1/10). > Then all drivers can be removed/updated - subsystem maintainers can pick their > patches freely. > > Finally, after getting rid of all Exynos5440 symbols, the last patch (10/10) > will > end in arm-soc tree. > > > Any comments? I don't see any hard dependency here, if this is all unused, I think we can apply both patches 1 and 10 into arm-soc at the same time as merging the other patches through the respective subsystem trees. Arnd
