| Message ID | 20210920190350.3860821-3-willmcvicker@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: Kconfig: Update ARCH_EXYNOS select configs | expand |
On 20/09/2021 21:03, Will McVicker wrote: > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to > be enabled by default via "default y if ARCH_EXYNOS" versus being > selected by the ARCH_EXYNOS config directly. This allows vendors to > disable these configs if they wish and provides additional flexibility > to modularize them in the presence of a generic kernel. This is not true. Vendors cannot disable these options as they are not visible. Although I understand that Arnd prefers this way and I do not object it, but your explanation is incorrect. > > There are no .config differences with this change. The configs > SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still > remain enabled by default. > > Signed-off-by: Will McVicker <willmcvicker@google.com> > --- > arch/arm64/Kconfig.platforms | 4 ---- > drivers/soc/samsung/Kconfig | 4 ++++ > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 3a66ed43088d..6a006490c9b9 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -91,14 +91,10 @@ config ARCH_BRCMSTB > > config ARCH_EXYNOS > bool "ARMv8 based Samsung Exynos SoC family" > - select EXYNOS_CHIPID This will conflict with: https://lore.kernel.org/linux-samsung-soc/CAGOxZ50i6URzUQ7o7V4m7MR=2TqSeD6qx5fQaQDs+5nEq4fa2A@mail.gmail.com/T/#t Build on top of it, please. Best regards, Krzysztof
On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > On 20/09/2021 21:03, Will McVicker wrote: > > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to > > be enabled by default via "default y if ARCH_EXYNOS" versus being > > selected by the ARCH_EXYNOS config directly. This allows vendors to > > disable these configs if they wish and provides additional flexibility > > to modularize them in the presence of a generic kernel. > > This is not true. Vendors cannot disable these options as they are not > visible. Good point, well made. > Although I understand that Arnd prefers this way and I do not > object it, but your explanation is incorrect.
On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote: > > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > > > On 20/09/2021 21:03, Will McVicker wrote: > > > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to > > > be enabled by default via "default y if ARCH_EXYNOS" versus being > > > selected by the ARCH_EXYNOS config directly. This allows vendors to > > > disable these configs if they wish and provides additional flexibility > > > to modularize them in the presence of a generic kernel. > > > > This is not true. Vendors cannot disable these options as they are not > > visible. > > Good point, well made. > > > Although I understand that Arnd prefers this way and I do not > > object it, but your explanation is incorrect. Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden configs" part. I'll upload the series to include the fix that refactos the Samsung SoC drivers menuconfig which will address that and allow one to enable/disable those configs. I'm going to hold off though until we hash out the rest of the discussion in the cover letter email. Thanks, Will > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog
On 21/09/2021 19:45, Will McVicker wrote: > On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote: >> >> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: >> >>> On 20/09/2021 21:03, Will McVicker wrote: >>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to >>>> be enabled by default via "default y if ARCH_EXYNOS" versus being >>>> selected by the ARCH_EXYNOS config directly. This allows vendors to >>>> disable these configs if they wish and provides additional flexibility >>>> to modularize them in the presence of a generic kernel. >>> >>> This is not true. Vendors cannot disable these options as they are not >>> visible. >> >> Good point, well made. >> >>> Although I understand that Arnd prefers this way and I do not >>> object it, but your explanation is incorrect. > > Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden > configs" part. I'll upload the series to include the fix that refactos > the Samsung SoC drivers menuconfig which will address that and allow > one to enable/disable those configs. I'm going to hold off though > until we hash out the rest of the discussion in the cover letter > email. No, please first read our discussions, including Lee's and Geert's comments. The drivers should not be converted to modules or made visible if such configuration does not work. If it works, please describe your testing setup. All these drivers are *necessary* for a multiplatform kernel supporting Exynos platforms, therefore disabling them does not make any sense (if you support Exynos platform). If your kernel does not support Exynos platform, just do not select ARCH_EXYNOS and problem disappears because none of these drivers will be visible and selected. Unless you describe here some out-of-tree kernel which wants ARCH_EXYNOS, because vendor did not upstream it's code, but you do not want existing Exynos upstream drivers. We do not support such configuration. Please push your lovely vendor to work with upstream. That's the only solution. It's the third time this abuse re-usage of ARCH_EXYNOS appears and the same as before - the vendor does not like to upstream stuff. There are few guys trying to upstream recent Samsung SoC support by themself (ping me for contacts if you would like to participate) but the one party which should be doing it - the lovely vendor - does not actually participate and instead sends ridiculous patches like this one here... or like this [1] [2]. Nope, please work with upstreaming SoC support, instead of abusing ARCH_EXYNOS for out of tree code from the vendor. [1] https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/ [2] https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/ Best regards, Krzysztof
On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > On 21/09/2021 19:45, Will McVicker wrote: > > On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote: > >> > >> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > >> > >>> On 20/09/2021 21:03, Will McVicker wrote: > >>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to > >>>> be enabled by default via "default y if ARCH_EXYNOS" versus being > >>>> selected by the ARCH_EXYNOS config directly. This allows vendors to > >>>> disable these configs if they wish and provides additional flexibility > >>>> to modularize them in the presence of a generic kernel. > >>> > >>> This is not true. Vendors cannot disable these options as they are not > >>> visible. > >> > >> Good point, well made. > >> > >>> Although I understand that Arnd prefers this way and I do not > >>> object it, but your explanation is incorrect. > > > > Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden > > configs" part. I'll upload the series to include the fix that refactos > > the Samsung SoC drivers menuconfig which will address that and allow > > one to enable/disable those configs. I'm going to hold off though > > until we hash out the rest of the discussion in the cover letter > > email. > > No, please first read our discussions, including Lee's and Geert's > comments. The drivers should not be converted to modules or made visible > if such configuration does not work. If it works, please describe your > testing setup. Modules *should* work. William is going to try it out. Might need to lean-on for some testing on different H/W though. > All these drivers are *necessary* for a multiplatform kernel supporting > Exynos platforms, therefore disabling them does not make any sense (if > you support Exynos platform). If your kernel does not support Exynos > platform, just do not select ARCH_EXYNOS and problem disappears because > none of these drivers will be visible and selected. > > Unless you describe here some out-of-tree kernel which wants > ARCH_EXYNOS, because vendor did not upstream it's code, but you do not > want existing Exynos upstream drivers. We do not support such > configuration. Please push your lovely vendor to work with upstream. > That's the only solution. > > It's the third time this abuse re-usage of ARCH_EXYNOS appears and the > same as before - the vendor does not like to upstream stuff. There are > few guys trying to upstream recent Samsung SoC support by themself (ping > me for contacts if you would like to participate) but the one party > which should be doing it - the lovely vendor - does not actually > participate and instead sends ridiculous patches like this one here... > or like this [1] [2]. > > Nope, please work with upstreaming SoC support, instead of abusing > ARCH_EXYNOS for out of tree code from the vendor. One of the on-going issues that GKI aims to solve pertains to the disparity between what upstream engineers would like to be upstreamed (i.e. everything) and what vendors can upstream (i.e. most things). The old Open Source vs Business (i.e. products/real-life) struggle! Vendors are not able to upstream all functionality right away, as it would give away their perceived edge on the competition (i.e. other vendors). This is something we just have to accept as it will *never* change. GKI attempts to solve this issue by providing a generic core containing all of the elements required to get every supported platform bootstrapped to a point where modules can be loaded and additional functionality can be brought in. GKI provides all of the modules available from the upstream kernel BUT allows them to be overwritten/swapped-out by modules containing code (new/shiny unreleased value-add) that the vendors do not wish to share (yet). Clever, eh! As I've explained before, the trigger for all of this was SERIAL_SAMSUNG which is required for early console on supported Samsung platforms i.e. this symbol *has* to be built-in. In order for this to built-in ARCH_EXYNOS has to be enabled due to the listed dependencies in Kconfig. And since ARCH_EXYNOS 'selects' all of these different extra symbols, it means they too will be built-in, meaning that a) the core binary will be unnecessarily bloated and b) vendors who wish to overwrite/replace this functionality with their non-shareable value-add, are not able to do so. Going forward, it sounds like the best approach that will make everyone happy, providing it's technically feasible, is to enable these added (sometimes required, other times superfluous) symbols as loadable modules. > [1] > https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/ > > [2] > https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/ > > Best regards, > Krzysztof
On 23/09/2021 14:39, Lee Jones wrote: > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > >> On 21/09/2021 19:45, Will McVicker wrote: >>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote: >>>> >>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: >>>> >>>>> On 20/09/2021 21:03, Will McVicker wrote: >>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to >>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being >>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to >>>>>> disable these configs if they wish and provides additional flexibility >>>>>> to modularize them in the presence of a generic kernel. >>>>> >>>>> This is not true. Vendors cannot disable these options as they are not >>>>> visible. >>>> >>>> Good point, well made. >>>> >>>>> Although I understand that Arnd prefers this way and I do not >>>>> object it, but your explanation is incorrect. >>> >>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden >>> configs" part. I'll upload the series to include the fix that refactos >>> the Samsung SoC drivers menuconfig which will address that and allow >>> one to enable/disable those configs. I'm going to hold off though >>> until we hash out the rest of the discussion in the cover letter >>> email. >> >> No, please first read our discussions, including Lee's and Geert's >> comments. The drivers should not be converted to modules or made visible >> if such configuration does not work. If it works, please describe your >> testing setup. > > Modules *should* work. William is going to try it out. > > Might need to lean-on for some testing on different H/W though. I can help, few other folks from Samsung can help as well. > >> All these drivers are *necessary* for a multiplatform kernel supporting >> Exynos platforms, therefore disabling them does not make any sense (if >> you support Exynos platform). If your kernel does not support Exynos >> platform, just do not select ARCH_EXYNOS and problem disappears because >> none of these drivers will be visible and selected. >> >> Unless you describe here some out-of-tree kernel which wants >> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not >> want existing Exynos upstream drivers. We do not support such >> configuration. Please push your lovely vendor to work with upstream. >> That's the only solution. >> >> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the >> same as before - the vendor does not like to upstream stuff. There are >> few guys trying to upstream recent Samsung SoC support by themself (ping >> me for contacts if you would like to participate) but the one party >> which should be doing it - the lovely vendor - does not actually >> participate and instead sends ridiculous patches like this one here... >> or like this [1] [2]. >> >> Nope, please work with upstreaming SoC support, instead of abusing >> ARCH_EXYNOS for out of tree code from the vendor. > > One of the on-going issues that GKI aims to solve pertains to the > disparity between what upstream engineers would like to be upstreamed > (i.e. everything) and what vendors can upstream (i.e. most things). > > The old Open Source vs Business (i.e. products/real-life) struggle! > > Vendors are not able to upstream all functionality right away, as it > would give away their perceived edge on the competition (i.e. other > vendors). This is something we just have to accept as it will *never* > change. Sure, I understand. Balance, compromise, not perfectness. However now it is heavily in-balanced since vendor did upstream only one change - UFS drivers for new SoC - since 2017. One change. Nothing else, nothing for older SoC, nothing for newer. All other work is done by the community, not by the vendor. Not sure how to qualify Sam's Exynos850 work, but even if counting it, there will be just two changes from vendor. This is not acceptable, this is not a balanced approach. > > GKI attempts to solve this issue by providing a generic core > containing all of the elements required to get every supported > platform bootstrapped to a point where modules can be loaded and > additional functionality can be brought in. GKI provides all of the > modules available from the upstream kernel BUT allows them to be > overwritten/swapped-out by modules containing code (new/shiny > unreleased value-add) that the vendors do not wish to share (yet). > > Clever, eh! > > As I've explained before, the trigger for all of this was > SERIAL_SAMSUNG which is required for early console on supported > Samsung platforms i.e. this symbol *has* to be built-in. Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary for built-in only for debugging or development, not for real products. Unlike other drivers which have to be built-in, e.g. clocks or pinctrl, or heavily tested whether setup from initrd works. Plus not breaking distros who like to have everything as module (solution from Geert?)... > In order for > this to built-in ARCH_EXYNOS has to be enabled due to the listed > dependencies in Kconfig. And since ARCH_EXYNOS 'selects' all of these > different extra symbols, it means they too will be built-in, meaning > that a) the core binary will be unnecessarily bloated and b) vendors > who wish to overwrite/replace this functionality with their > non-shareable value-add, are not able to do so. I am sorry, but this is not reflecting status we want to have in usptream. Everything selected by ARCH_EXYNOS *has to be selected* for supported platforms. Since vendor does not contribute anything new (except mentioned one work for UFS), we are not going to sacrifice supported mainline platforms for a non-cooperative out-of-tree unknown platforms. > Going forward, it sounds like the best approach that will make > everyone happy, providing it's technically feasible, is to enable > these added (sometimes required, other times superfluous) symbols as > loadable modules. Not entirely. What actually would make everyone happy and it is still technically feasible is for a multi-billion company with thousands of engineers to contribute something. Let's start with a little bit. From billions of dollars and thousands of engineers we won't expect too much, right? Best regards, Krzysztof
On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote: > On 23/09/2021 14:39, Lee Jones wrote: > > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > > > >> On 21/09/2021 19:45, Will McVicker wrote: > >>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote: > >>>> > >>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > >>>> > >>>>> On 20/09/2021 21:03, Will McVicker wrote: > >>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to > >>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being > >>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to > >>>>>> disable these configs if they wish and provides additional flexibility > >>>>>> to modularize them in the presence of a generic kernel. > >>>>> > >>>>> This is not true. Vendors cannot disable these options as they are not > >>>>> visible. > >>>> > >>>> Good point, well made. > >>>> > >>>>> Although I understand that Arnd prefers this way and I do not > >>>>> object it, but your explanation is incorrect. > >>> > >>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden > >>> configs" part. I'll upload the series to include the fix that refactos > >>> the Samsung SoC drivers menuconfig which will address that and allow > >>> one to enable/disable those configs. I'm going to hold off though > >>> until we hash out the rest of the discussion in the cover letter > >>> email. > >> > >> No, please first read our discussions, including Lee's and Geert's > >> comments. The drivers should not be converted to modules or made visible > >> if such configuration does not work. If it works, please describe your > >> testing setup. > > > > Modules *should* work. William is going to try it out. > > > > Might need to lean-on for some testing on different H/W though. > > I can help, few other folks from Samsung can help as well. Thanks. I'd really appreciate it. > >> All these drivers are *necessary* for a multiplatform kernel supporting > >> Exynos platforms, therefore disabling them does not make any sense (if > >> you support Exynos platform). If your kernel does not support Exynos > >> platform, just do not select ARCH_EXYNOS and problem disappears because > >> none of these drivers will be visible and selected. > >> > >> Unless you describe here some out-of-tree kernel which wants > >> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not > >> want existing Exynos upstream drivers. We do not support such > >> configuration. Please push your lovely vendor to work with upstream. > >> That's the only solution. > >> > >> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the > >> same as before - the vendor does not like to upstream stuff. There are > >> few guys trying to upstream recent Samsung SoC support by themself (ping > >> me for contacts if you would like to participate) but the one party > >> which should be doing it - the lovely vendor - does not actually > >> participate and instead sends ridiculous patches like this one here... > >> or like this [1] [2]. > >> > >> Nope, please work with upstreaming SoC support, instead of abusing > >> ARCH_EXYNOS for out of tree code from the vendor. > > > > One of the on-going issues that GKI aims to solve pertains to the > > disparity between what upstream engineers would like to be upstreamed > > (i.e. everything) and what vendors can upstream (i.e. most things). > > > > The old Open Source vs Business (i.e. products/real-life) struggle! > > > > Vendors are not able to upstream all functionality right away, as it > > would give away their perceived edge on the competition (i.e. other > > vendors). This is something we just have to accept as it will *never* > > change. > > Sure, I understand. Balance, compromise, not perfectness. > > However now it is heavily in-balanced since vendor did upstream only one > change - UFS drivers for new SoC - since 2017. One change. Nothing else, > nothing for older SoC, nothing for newer. > > All other work is done by the community, not by the vendor. > > Not sure how to qualify Sam's Exynos850 work, but even if counting it, > there will be just two changes from vendor. > > This is not acceptable, this is not a balanced approach. Completely understand. Been there, got frustrated by that! However, GKI is your friend here, since it operates an upstream-first philosophy. Samsung would not be able to utilise GKI if its platform wasn't supported by upstream. Regardless of who did the work, (not my concern at this point) the platform is supported in Mainline. Volunteers (including Linaro) do a bunch of upstreaming on behalf of vendors, including some of the very largest/most successful. Sometimes that just the way it goes - try not to take it too personally. > > GKI attempts to solve this issue by providing a generic core > > containing all of the elements required to get every supported > > platform bootstrapped to a point where modules can be loaded and > > additional functionality can be brought in. GKI provides all of the > > modules available from the upstream kernel BUT allows them to be > > overwritten/swapped-out by modules containing code (new/shiny > > unreleased value-add) that the vendors do not wish to share (yet). > > > > Clever, eh! > > > > As I've explained before, the trigger for all of this was > > SERIAL_SAMSUNG which is required for early console on supported > > Samsung platforms i.e. this symbol *has* to be built-in. > > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary > for built-in only for debugging or development, not for real products. Right. And in the early stages, GKI is used for early (non-released) H/W (this is also the part of the reason these differences can't be upstreamed early/now/yet) and sometimes changes break things requiring low-level debugging techniques to solve (inc. early console). > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl, > or heavily tested whether setup from initrd works. Plus not breaking > distros who like to have everything as module (solution from Geert?)... We don't know which drivers *need* to be built-in yet. Clocks is probably not a good example even, since the power-on default is most likely all-on, which is fine. Pinctrl remains to be seen. > > In order for > > this to built-in ARCH_EXYNOS has to be enabled due to the listed > > dependencies in Kconfig. And since ARCH_EXYNOS 'selects' all of these > > different extra symbols, it means they too will be built-in, meaning > > that a) the core binary will be unnecessarily bloated and b) vendors > > who wish to overwrite/replace this functionality with their > > non-shareable value-add, are not able to do so. > > I am sorry, but this is not reflecting status we want to have in > usptream. Everything selected by ARCH_EXYNOS *has to be selected* for > supported platforms. Since vendor does not contribute anything new > (except mentioned one work for UFS), we are not going to sacrifice > supported mainline platforms for a non-cooperative out-of-tree unknown > platforms. The is the part of the discussion that is the most contentious. Ideally we wouldn't have to enable any ARCH_* explicitly. Greg has mentioned this publicly on a number of discussions. However, removing the dependencies (from Kconfig in this case) is in contention with other user's use-cases. No one wants to be asked seemingly irrelevant configuration questions during the config stages of a kernel build. So we are forced to enable ARCH_* to have our requirements built-in (ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case). Unfortunately, this comes with additional cruft that we *might* not want (resulting in bloat) or that we wish to overwrite with more featureful driver modules. We can't do that if these features are built-in. Please don't make this discussion about particular vendors. Bringing in emotional feelings pertaining to specific companies or individuals does not make for a quality level-headed technical discussion. The principles I'm discussing here are vendor agnostic. > > Going forward, it sounds like the best approach that will make > > everyone happy, providing it's technically feasible, is to enable > > these added (sometimes required, other times superfluous) symbols as > > loadable modules. > > Not entirely. What actually would make everyone happy and it is still > technically feasible is for a multi-billion company with thousands of > engineers to contribute something. Let's start with a little bit. From > billions of dollars and thousands of engineers we won't expect too much, > right? I understand your frustration, but it's orthogonal to this discussion.
Hi Lee, On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote: > On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote: > > On 23/09/2021 14:39, Lee Jones wrote: > > > As I've explained before, the trigger for all of this was > > > SERIAL_SAMSUNG which is required for early console on supported > > > Samsung platforms i.e. this symbol *has* to be built-in. > > > > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary > > for built-in only for debugging or development, not for real products. > > Right. And in the early stages, GKI is used for early (non-released) > H/W (this is also the part of the reason these differences can't be > upstreamed early/now/yet) and sometimes changes break things requiring > low-level debugging techniques to solve (inc. early console). > > > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl, > > or heavily tested whether setup from initrd works. Plus not breaking > > distros who like to have everything as module (solution from Geert?)... > > We don't know which drivers *need* to be built-in yet. > > Clocks is probably not a good example even, since the power-on default > is most likely all-on, which is fine. Pinctrl remains to be seen. Clocks is an excellent example: if a clock is missing, the driver will fail to probe (unless the clock is considered optional by the driver), regardless of the power-on or boot loader defaults. With fw_devlinks=on (which is the default now, and developed by a Google engineer (GKI or another division?)), the driver won't even get to the probing point. Pinctrl is different, as unless I'm mistaken, drivers will still probe if the pin control driver is missing, so they will work if the power-on or boot loader defaults of pin control are fine. > > > In order for > > > this to built-in ARCH_EXYNOS has to be enabled due to the listed > > > dependencies in Kconfig. And since ARCH_EXYNOS 'selects' all of these > > > different extra symbols, it means they too will be built-in, meaning > > > that a) the core binary will be unnecessarily bloated and b) vendors > > > who wish to overwrite/replace this functionality with their > > > non-shareable value-add, are not able to do so. > > > > I am sorry, but this is not reflecting status we want to have in > > usptream. Everything selected by ARCH_EXYNOS *has to be selected* for > > supported platforms. Since vendor does not contribute anything new > > (except mentioned one work for UFS), we are not going to sacrifice > > supported mainline platforms for a non-cooperative out-of-tree unknown > > platforms. > > The is the part of the discussion that is the most contentious. > > Ideally we wouldn't have to enable any ARCH_* explicitly. Greg has > mentioned this publicly on a number of discussions. However, removing > the dependencies (from Kconfig in this case) is in contention with > other user's use-cases. No one wants to be asked seemingly irrelevant > configuration questions during the config stages of a kernel build. > > So we are forced to enable ARCH_* to have our requirements built-in > (ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case). > Unfortunately, this comes with additional cruft that we *might* not > want (resulting in bloat) or that we wish to overwrite with more > featureful driver modules. We can't do that if these features are > built-in. The question is if Linux can actually boot on the affected platform without this "additional cruft" builtin, for which we still haven't received any confirmation yet... So claiming to be "upstream first", and submitting patches, is great, but only if the changes you're upstreaming actually work. If they don't, and if you insist on keeping on upstreaming them, without providing evidence that they don't break the affected platform completely, perhaps this should be treated similar to the UMN patches? Gr{oetje,eeting}s, Geert
On Thu, Sep 23, 2021 at 6:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote: > > On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote: > > > On 23/09/2021 14:39, Lee Jones wrote: > > > > As I've explained before, the trigger for all of this was > > > > SERIAL_SAMSUNG which is required for early console on supported > > > > Samsung platforms i.e. this symbol *has* to be built-in. > > > > > > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary > > > for built-in only for debugging or development, not for real products. > > > > Right. And in the early stages, GKI is used for early (non-released) > > H/W (this is also the part of the reason these differences can't be > > upstreamed early/now/yet) and sometimes changes break things requiring > > low-level debugging techniques to solve (inc. early console). > > > > > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl, > > > or heavily tested whether setup from initrd works. Plus not breaking > > > distros who like to have everything as module (solution from Geert?)... > > > > We don't know which drivers *need* to be built-in yet. > > > > Clocks is probably not a good example even, since the power-on default > > is most likely all-on, which is fine. Pinctrl remains to be seen. > > Clocks is an excellent example: if a clock is missing, the driver > will fail to probe (unless the clock is considered optional by > the driver), regardless of the power-on or boot loader defaults. > With fw_devlinks=on (which is the default now, and developed by a > Google engineer (GKI or another division?)), the driver won't even > get to the probing point. > > Pinctrl is different, as unless I'm mistaken, drivers will still > probe if the pin control driver is missing, so they will work if the > power-on or boot loader defaults of pin control are fine. In addition, relying on implicit power-on or boot loader state comes with its own set of pitfalls, which may break other use cases. On a heavily power-managed mobile device, clocks and/or power domains can be turned off, so a kernel launched from kexec or kdump may start in a state not adhering to these implicit dependencies. Gr{oetje,eeting}s, Geert
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 3a66ed43088d..6a006490c9b9 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -91,14 +91,10 @@ config ARCH_BRCMSTB config ARCH_EXYNOS bool "ARMv8 based Samsung Exynos SoC family" - select EXYNOS_CHIPID - select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS - select EXYNOS_PMU select HAVE_S3C_RTC if RTC_CLASS select PINCTRL select PINCTRL_EXYNOS select PM_GENERIC_DOMAINS if PM - select SOC_SAMSUNG help This enables support for ARMv8 based Samsung Exynos SoC family. diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig index 5745d7e5908e..9402c02bc9de 100644 --- a/drivers/soc/samsung/Kconfig +++ b/drivers/soc/samsung/Kconfig @@ -4,6 +4,7 @@ # menuconfig SOC_SAMSUNG bool "Samsung SoC driver support" if COMPILE_TEST + default y if ARCH_EXYNOS if SOC_SAMSUNG @@ -15,6 +16,7 @@ config EXYNOS_ASV_ARM config EXYNOS_CHIPID bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST depends on ARCH_EXYNOS || COMPILE_TEST + default y if ARCH_EXYNOS select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS select MFD_SYSCON select SOC_BUS @@ -24,6 +26,7 @@ config EXYNOS_CHIPID config EXYNOS_PMU bool "Exynos PMU controller driver" if COMPILE_TEST depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST) + default y if ARCH_EXYNOS select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS # There is no need to enable these drivers for ARMv8 @@ -34,6 +37,7 @@ config EXYNOS_PMU_ARM_DRIVERS config EXYNOS_PM_DOMAINS bool "Exynos PM domains" if COMPILE_TEST depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST + default y if (ARCH_EXYNOS && PM_GENERIC_DOMAINS) config SAMSUNG_PM_DEBUG bool "Samsung PM Suspend debug"
Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to be enabled by default via "default y if ARCH_EXYNOS" versus being selected by the ARCH_EXYNOS config directly. This allows vendors to disable these configs if they wish and provides additional flexibility to modularize them in the presence of a generic kernel. There are no .config differences with this change. The configs SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still remain enabled by default. Signed-off-by: Will McVicker <willmcvicker@google.com> --- arch/arm64/Kconfig.platforms | 4 ---- drivers/soc/samsung/Kconfig | 4 ++++ 2 files changed, 4 insertions(+), 4 deletions(-)