On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@xxxxxxxxxx> wrote: > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: > > > > On 29/09/2021 01:56, Will McVicker wrote: > > > This is v2 of the series of patches that modularizes a number of core > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have > > > modularized all of the drivers that are removed from the ARCH_EXYNOS > > > series of "select XXX". This includes setting the following configs as > > > tristate: > > > > > > * COMMON_CLK_SAMSUNG > > > * EXYNOS_ARM64_COMMON_CLK > > > * PINCTRL_SAMSUNG > > > * PINCTRL_EXYNOS > > > * EXYNOS_PMU_ARM64 > > > * EXYNOS_PM_DOMAINS > > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively. > > > The reason for these new configs is because we are not able to easily > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up > > > the ARM and ARM64 portions into two separate configs. > > > > > > Overall, these drivers didn't require much refactoring and converted to > > > modules relatively easily. However, due to my lack of exynos hardware, I > > > was not able to boot test these changes. I'm mostly concerned about the > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm > > > requesting help for testing these changes on the respective hardware. > > > > > > > These are all not tested at all? In such case, since these are not > > trivial changes, please mark the series as RFT. > > > > I will not be able to test these for some days, so it must wait. > > > > > > Best regards, > > Krzysztof > > +Cc Arnd and Olof, > > Hi Krzysztof, > > To avoid the scrambled conversation from the first patchset, I'm going > to address all your general questions here in the cover letter thread > so that it's easier for everyone to follow and reference in the > future. This patchset shouldn't go in. GKI is a fantastic effort, since it finally seems like Google has the backbone to put pressure on the vendors to upstream all their stuff. This patcheset dilutes and undermines all of that by opening up a truck-size loophole, reducing the impact of GKI, and overall removes leverage to get vendors to do the right thing. It's against our interest as a community to have this happen, since there's no other reasonably justifiable reason to do this. -Olof
