On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@xxxxxxxxx> wrote: > > > > 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. > > Oolf, Geert, Krzysztof, Arnd, So close. > I skimmed through the emails and you all make a lot of good points. I skimmed through this email and I think it adds a lot of new complexity and fragility to solve a problem that doesn't really exist for upstream, adding yet more config parameter combinations to build and test for. A much more valuable approach would be to work towards being able to free up memory by un-probed drivers at the end of boot. That would possibly benefit all platforms on all architectures. -Olof
