From: Marcel Ziswiler <marcel.ziswiler@toradex.com> To: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "krzysztof.kozlowski@canonical.com" <krzysztof.kozlowski@canonical.com> Cc: "enric.balletbo@collabora.com" <enric.balletbo@collabora.com>, "marek.vasut@gmail.com" <marek.vasut@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "biju.das.jz@bp.renesas.com" <biju.das.jz@bp.renesas.com>, "olof@lixom.net" <olof@lixom.net>, "arnd@arndb.de" <arnd@arndb.de>, "geert+renesas@glider.be" <geert+renesas@glider.be>, "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "shawnguo@kernel.org" <shawnguo@kernel.org> Subject: Re: [PATCH v2 05/11] arm64: defconfig: rebuild default configuration Date: Mon, 17 Jan 2022 12:05:18 +0000 [thread overview] Message-ID: <a5cfdd2ea149490abeb481c7a85d59019ea3c620.camel@toradex.com> (raw) In-Reply-To: <060a9f66-fc00-2247-46f2-1c700d0e9bf3@canonical.com> On Sat, 2022-01-15 at 18:02 +0100, Krzysztof Kozlowski wrote: > On 14/01/2022 15:15, Marcel Ziswiler wrote: > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com> > > > > Run "make defconfig; make savedefconfig" to rebuild defconfig. > > > > This re-ordered the following configuration options: > > > > CONFIG_BPF_JIT=y > > CONFIG_ARM_SCMI_PROTOCOL=y > > CONFIG_ARM_SCPI_PROTOCOL=y > > CONFIG_RASPBERRYPI_FIRMWARE=y > > CONFIG_INTEL_STRATIX10_SERVICE=y > > CONFIG_INTEL_STRATIX10_RSU=m > > CONFIG_EFI_CAPSULE_LOADER=y > > CONFIG_IMX_SCU=y > > CONFIG_IMX_SCU_PD=y > > CONFIG_CAN_FLEXCAN=m > > CONFIG_PCIE_LAYERSCAPE_GEN4=y > > CONFIG_MTK_DEVAPC=m > > CONFIG_SPI_CADENCE_QUADSPI=y > > CONFIG_MDIO_BUS_MUX_MMIOREG=y > > CONFIG_MDIO_BUS_MUX_MULTIPLEXER=y > > CONFIG_MESON_GXL_PHY=m > > CONFIG_QCOM_CPR=y > > CONFIG_ROCKCHIP_IODOMAIN=y > > CONFIG_SENSORS_ARM_SCMI=y > > CONFIG_QORIQ_THERMAL=m > > CONFIG_SUN8I_THERMAL=y > > CONFIG_TEGRA_BPMP_THERMAL=m > > CONFIG_ARM_SMC_WATCHDOG=y > > CONFIG_VIDEO_QCOM_CAMSS=m > > CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m > > CONFIG_DRM_NWL_MIPI_DSI=m > > CONFIG_DRM_LONTIUM_LT9611UXC=m > > CONFIG_SND_SOC_IMX_AUDMIX=m > > CONFIG_TYPEC_HD3SS3220=m > > CONFIG_COMMON_CLK_SCMI=y > > CONFIG_IPQ_GCC_8074=y > > CONFIG_SM_DISPCC_8250=y > > CONFIG_QCOM_WCNSS_CTRL=m > > CONFIG_ARCH_R8A774A1=y > > CONFIG_ARCH_R8A774B1=y > > CONFIG_ARCH_R8A774C0=y > > CONFIG_ARCH_R8A774E1=y > > CONFIG_ARCH_R8A77995=y > > CONFIG_ARCH_R8A77990=y > > CONFIG_ARCH_R8A77965=y > > CONFIG_ARCH_R8A77970=y > > CONFIG_HISI_PMU=y > > CONFIG_QCOM_QFPROM=y > > CONFIG_MUX_MMIO=y > > Thanks for the changes. > The best would be to have a separate patch only for re-ordering. Yes, from a review perspective that makes sense. Will do so in v3. > > And dropped the following configuration options which are nowaday's > > already enabled (resp. disabled) by default: > > > > CONFIG_MEMCG_SWAP=y > > CONFIG_SECCOMP=y > > Is it? I tried now on next-20220114 and it is still user-selectable and > not chosen by anything. Hm, strange. I guess, it is due to this whole patch series, given its i.MX main focus, being based on Shawn's for-next branch. Maybe for such defconfig changes it would be better to base them on something else? Not sure, who will ultimately pull such changes. Any suggestion? > > CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > > CONFIG_QCOM_SCM=y > > # CONFIG_BT_HS is not set > > CONFIG_FSL_MC_BUS=y > > CONFIG_MEDIA_CONTROLLER=y > > CONFIG_VIDEO_V4L2_SUBDEV_API=y > > CONFIG_SND_SOC_FSL_SAI=m > > CONFIG_USB_CONN_GPIO=m > > CONFIG_USB_XHCI_PCI=m > > CONFIG_MFD_CROS_EC_DEV=y > > CONFIG_COMMON_CLK_ZYNQMP=y > > CONFIG_SDM_GCC_845=y > > CONFIG_SM_GCC_8150=y > > CONFIG_SM_GCC_8250=y > > CONFIG_SLIMBUS=m > > CONFIG_INTERCONNECT=y > > CONFIG_CONFIGFS_FS=y > > All three above are still user-selectable, so please leave them. It is > redundant, but there is no guarantee that something selecting a > user-visible symbol will stop selecting it. IOW, user-visible symbols > should be still chosen by defconfigs if they really want them. Well, but even if they are already enabled anyway? What is the point of savedefconfig then resp. you are saying that the commited defconfigs should not be generated using savedefconfig? That sounds rather confusing to me. > See for example commit a2315d3aea59 ("ARM: exynos_defconfig: Restore > debugfs support") for rationale why we need to keep them. Okay, I see what you mean as in relation to above mentioned commit but then any change to Kconfig dependencies can ultimately change the behaviour of previous configs unless they are complete ones (or were just lucky to include whatever stuff that changed). But how should one now know which of them zillions of user-selectable options should be added to such "more robust" defconfigs? I suggest a better approach might be to have some CI which validates defconfig changes. That way one could easily track stuff disappearing and could at that point explicitly enable it again. > Best regards, > Krzysztof Cheers Marcel
WARNING: multiple messages have this Message-ID (diff)
From: Marcel Ziswiler <marcel.ziswiler@toradex.com> To: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "krzysztof.kozlowski@canonical.com" <krzysztof.kozlowski@canonical.com> Cc: "enric.balletbo@collabora.com" <enric.balletbo@collabora.com>, "marek.vasut@gmail.com" <marek.vasut@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "biju.das.jz@bp.renesas.com" <biju.das.jz@bp.renesas.com>, "olof@lixom.net" <olof@lixom.net>, "arnd@arndb.de" <arnd@arndb.de>, "geert+renesas@glider.be" <geert+renesas@glider.be>, "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "shawnguo@kernel.org" <shawnguo@kernel.org> Subject: Re: [PATCH v2 05/11] arm64: defconfig: rebuild default configuration Date: Mon, 17 Jan 2022 12:05:18 +0000 [thread overview] Message-ID: <a5cfdd2ea149490abeb481c7a85d59019ea3c620.camel@toradex.com> (raw) In-Reply-To: <060a9f66-fc00-2247-46f2-1c700d0e9bf3@canonical.com> On Sat, 2022-01-15 at 18:02 +0100, Krzysztof Kozlowski wrote: > On 14/01/2022 15:15, Marcel Ziswiler wrote: > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com> > > > > Run "make defconfig; make savedefconfig" to rebuild defconfig. > > > > This re-ordered the following configuration options: > > > > CONFIG_BPF_JIT=y > > CONFIG_ARM_SCMI_PROTOCOL=y > > CONFIG_ARM_SCPI_PROTOCOL=y > > CONFIG_RASPBERRYPI_FIRMWARE=y > > CONFIG_INTEL_STRATIX10_SERVICE=y > > CONFIG_INTEL_STRATIX10_RSU=m > > CONFIG_EFI_CAPSULE_LOADER=y > > CONFIG_IMX_SCU=y > > CONFIG_IMX_SCU_PD=y > > CONFIG_CAN_FLEXCAN=m > > CONFIG_PCIE_LAYERSCAPE_GEN4=y > > CONFIG_MTK_DEVAPC=m > > CONFIG_SPI_CADENCE_QUADSPI=y > > CONFIG_MDIO_BUS_MUX_MMIOREG=y > > CONFIG_MDIO_BUS_MUX_MULTIPLEXER=y > > CONFIG_MESON_GXL_PHY=m > > CONFIG_QCOM_CPR=y > > CONFIG_ROCKCHIP_IODOMAIN=y > > CONFIG_SENSORS_ARM_SCMI=y > > CONFIG_QORIQ_THERMAL=m > > CONFIG_SUN8I_THERMAL=y > > CONFIG_TEGRA_BPMP_THERMAL=m > > CONFIG_ARM_SMC_WATCHDOG=y > > CONFIG_VIDEO_QCOM_CAMSS=m > > CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m > > CONFIG_DRM_NWL_MIPI_DSI=m > > CONFIG_DRM_LONTIUM_LT9611UXC=m > > CONFIG_SND_SOC_IMX_AUDMIX=m > > CONFIG_TYPEC_HD3SS3220=m > > CONFIG_COMMON_CLK_SCMI=y > > CONFIG_IPQ_GCC_8074=y > > CONFIG_SM_DISPCC_8250=y > > CONFIG_QCOM_WCNSS_CTRL=m > > CONFIG_ARCH_R8A774A1=y > > CONFIG_ARCH_R8A774B1=y > > CONFIG_ARCH_R8A774C0=y > > CONFIG_ARCH_R8A774E1=y > > CONFIG_ARCH_R8A77995=y > > CONFIG_ARCH_R8A77990=y > > CONFIG_ARCH_R8A77965=y > > CONFIG_ARCH_R8A77970=y > > CONFIG_HISI_PMU=y > > CONFIG_QCOM_QFPROM=y > > CONFIG_MUX_MMIO=y > > Thanks for the changes. > The best would be to have a separate patch only for re-ordering. Yes, from a review perspective that makes sense. Will do so in v3. > > And dropped the following configuration options which are nowaday's > > already enabled (resp. disabled) by default: > > > > CONFIG_MEMCG_SWAP=y > > CONFIG_SECCOMP=y > > Is it? I tried now on next-20220114 and it is still user-selectable and > not chosen by anything. Hm, strange. I guess, it is due to this whole patch series, given its i.MX main focus, being based on Shawn's for-next branch. Maybe for such defconfig changes it would be better to base them on something else? Not sure, who will ultimately pull such changes. Any suggestion? > > CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > > CONFIG_QCOM_SCM=y > > # CONFIG_BT_HS is not set > > CONFIG_FSL_MC_BUS=y > > CONFIG_MEDIA_CONTROLLER=y > > CONFIG_VIDEO_V4L2_SUBDEV_API=y > > CONFIG_SND_SOC_FSL_SAI=m > > CONFIG_USB_CONN_GPIO=m > > CONFIG_USB_XHCI_PCI=m > > CONFIG_MFD_CROS_EC_DEV=y > > CONFIG_COMMON_CLK_ZYNQMP=y > > CONFIG_SDM_GCC_845=y > > CONFIG_SM_GCC_8150=y > > CONFIG_SM_GCC_8250=y > > CONFIG_SLIMBUS=m > > CONFIG_INTERCONNECT=y > > CONFIG_CONFIGFS_FS=y > > All three above are still user-selectable, so please leave them. It is > redundant, but there is no guarantee that something selecting a > user-visible symbol will stop selecting it. IOW, user-visible symbols > should be still chosen by defconfigs if they really want them. Well, but even if they are already enabled anyway? What is the point of savedefconfig then resp. you are saying that the commited defconfigs should not be generated using savedefconfig? That sounds rather confusing to me. > See for example commit a2315d3aea59 ("ARM: exynos_defconfig: Restore > debugfs support") for rationale why we need to keep them. Okay, I see what you mean as in relation to above mentioned commit but then any change to Kconfig dependencies can ultimately change the behaviour of previous configs unless they are complete ones (or were just lucky to include whatever stuff that changed). But how should one now know which of them zillions of user-selectable options should be added to such "more robust" defconfigs? I suggest a better approach might be to have some CI which validates defconfig changes. That way one could easily track stuff disappearing and could at that point explicitly enable it again. > Best regards, > Krzysztof Cheers Marcel _______________________________________________ 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 12:05 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-14 14:14 [PATCH v2 00/11] arm64: prepare and add verdin imx8m mini support Marcel Ziswiler 2022-01-14 14:14 ` [PATCH v2 01/11] arm64: dts: imx8mm: fix strange hex notation Marcel Ziswiler 2022-01-14 14:14 ` Marcel Ziswiler 2022-01-14 14:14 ` [PATCH v2 02/11] dt-bindings: gpio: fix gpio-hog example Marcel Ziswiler 2022-01-14 14:14 ` Marcel Ziswiler 2022-01-16 12:13 ` Linus Walleij 2022-01-16 12:13 ` Linus Walleij 2022-01-25 9:13 ` Bartosz Golaszewski 2022-01-25 9:13 ` Bartosz Golaszewski 2022-01-14 14:14 ` [PATCH v2 03/11] arm64: defconfig: enable taskstats configuration Marcel Ziswiler 2022-01-14 14:14 ` Marcel Ziswiler 2022-01-15 16:42 ` Krzysztof Kozlowski 2022-01-15 16:42 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 04/11] arm64: defconfig: enable pcieaer configuration Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 16:45 ` Krzysztof Kozlowski 2022-01-15 16:45 ` Krzysztof Kozlowski 2022-01-17 11:45 ` Marcel Ziswiler 2022-01-17 11:45 ` Marcel Ziswiler 2022-01-17 11:47 ` Krzysztof Kozlowski 2022-01-17 11:47 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 05/11] arm64: defconfig: rebuild default configuration Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 17:02 ` Krzysztof Kozlowski 2022-01-15 17:02 ` Krzysztof Kozlowski 2022-01-17 12:05 ` Marcel Ziswiler [this message] 2022-01-17 12:05 ` Marcel Ziswiler 2022-01-17 12:49 ` Krzysztof Kozlowski 2022-01-17 12:49 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 06/11] arm64: defconfig: enable bpf/cgroup firewalling Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 07/11] arm64: defconfig: build imx-sdma as a module Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-14 14:15 ` [PATCH v2 08/11] arm64: defconfig: build r8169 " Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-15 16:47 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 09/11] arm64: defconfig: enable verdin-imx8mm relevant drivers as modules Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 16:48 ` Krzysztof Kozlowski 2022-01-15 16:48 ` Krzysztof Kozlowski 2022-01-14 14:15 ` [PATCH v2 10/11] dt-bindings: arm: fsl: add toradex,verdin-imx8mm et al Marcel Ziswiler 2022-01-14 14:15 ` [PATCH v2 10/11] dt-bindings: arm: fsl: add toradex, verdin-imx8mm " Marcel Ziswiler 2022-01-14 14:15 ` [PATCH v2 11/11] arm64: dts: freescale: add initial support for verdin imx8m mini Marcel Ziswiler 2022-01-14 14:15 ` Marcel Ziswiler 2022-01-15 16:50 ` Krzysztof Kozlowski 2022-01-15 16:50 ` Krzysztof Kozlowski
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=a5cfdd2ea149490abeb481c7a85d59019ea3c620.camel@toradex.com \ --to=marcel.ziswiler@toradex.com \ --cc=arnd@arndb.de \ --cc=biju.das.jz@bp.renesas.com \ --cc=bjorn.andersson@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=enric.balletbo@collabora.com \ --cc=geert+renesas@glider.be \ --cc=krzysztof.kozlowski@canonical.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marek.vasut@gmail.com \ --cc=olof@lixom.net \ --cc=shawnguo@kernel.org \ --cc=will@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.