| Message ID | 20220307143421.1106209-14-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: suniv: dts: update Allwinner F1C100 | expand |
On Mon, Mar 7, 2022 at 3:34 PM Andre Przywara <andre.przywara@arm.com> wrote: > > Some Kconfig options have changed, some other platforms have been > removed. Please split this up into logical chunks: list the platforms that were removed and remove only the lines corresponding to those platforms in one patch, do functional changes in separate patches each with a reason for doing them, and cleanups (moving lines to match the savedefconfig output, removing lines that are now the default) in one final patch. > CONFIG_AEABI=y > CONFIG_HIGHMEM=y > -CONFIG_ZBOOT_ROM_TEXT=0x0 > -CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CPU_FREQ=y These were not removed, what happened here is that 'savedefconfig' no longer produces the lines because they now match the defaults. > @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m > CONFIG_I2C_AT91=y > CONFIG_I2C_IMX=y > CONFIG_I2C_MV64XXX=y > -CONFIG_I2C_NOMADIK=y > CONFIG_SPI=y > CONFIG_SPI_ATMEL=y > CONFIG_SPI_IMX=y This one is still there. Not sure why it's no longer enabled. > CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_MEDIA_SUPPORT=y > CONFIG_MEDIA_CAMERA_SUPPORT=y > -CONFIG_V4L_PLATFORM_DRIVERS=y > -CONFIG_VIDEO_ASPEED=m > -CONFIG_VIDEO_ATMEL_ISI=m > CONFIG_DRM=y > CONFIG_DRM_ATMEL_HLCDC=m > -CONFIG_DRM_PANEL_SIMPLE=y > -CONFIG_DRM_PANEL_EDP=y > CONFIG_DRM_ASPEED_GFX=m > -CONFIG_FB_IMX=y > -CONFIG_FB_ATMEL=y > -CONFIG_BACKLIGHT_ATMEL_LCDC=y This doesn't look right at all. If you want to disable graphics support, please do that in a separate patch and explain why we can't have those any more. Are you running into problems with the vmlinux size? > CONFIG_LIBCRC32C=y > CONFIG_DEBUG_INFO=y > -CONFIG_DEBUG_FS=y > CONFIG_MAGIC_SYSRQ=y > +CONFIG_DEBUG_FS=y > CONFIG_DEBUG_KERNEL=y > # CONFIG_SCHED_DEBUG is not set > # CONFIG_DEBUG_PREEMPT is not set This should probably go along with the ZBOOT_ROM change, it's only cosmetic. Arnd
On Tue, 8 Mar 2022 10:38:37 +0100 Arnd Bergmann <arnd@arndb.de> wrote: Hi Arnd, thanks for having a look. I was a bit unsure about the policy of those changes, so glad to have the discussion. > On Mon, Mar 7, 2022 at 3:34 PM Andre Przywara <andre.przywara@arm.com> wrote: > > > > Some Kconfig options have changed, some other platforms have been > > removed. > > Please split this up into logical chunks: list the platforms that were removed > and remove only the lines corresponding to those platforms in one patch, > do functional changes in separate patches each with a reason for doing them, > and cleanups (moving lines to match the savedefconfig output, removing lines > that are now the default) in one final patch. Actually this patch is meant to be only about the last past: to sync multi_v5_defconfig with the output of "make savedefconfig". .config stays the same. I initially tried to chase down the reason for each line change, but gave up quickly, because it becomes tedious to learn about this, especially about symbols that got *removed*. Also Kconfig is somewhat sensitive, a single "select" or "default" change in one random Kconfig can affect the result of savedefconfig. As I noted in the commit message, the .config does *not* change as a result of this patch, the whole purpose is just to make the next patch clearer. So I can try find the reason for each removal, if you like, but I am not sure that's worthwhile? It is my understanding that Kconfig changes tend to accumulate cruft in the various defconfigs over time. In U-Boot we gave up on reasoning, and just regularly sync the output of savedefconfig over to the *_defconfigs, to keep them minimal and meaningful. And I found Olof's commit 30b10c77837c ("ARM: defconfig: re-run savedefconfig on multi_v* configs") as a precedence for this kind of cleanup. > > CONFIG_AEABI=y > > CONFIG_HIGHMEM=y > > -CONFIG_ZBOOT_ROM_TEXT=0x0 > > -CONFIG_ZBOOT_ROM_BSS=0x0 > > CONFIG_ARM_APPENDED_DTB=y > > CONFIG_ARM_ATAG_DTB_COMPAT=y > > CONFIG_CPU_FREQ=y > > These were not removed, what happened here is that 'savedefconfig' > no longer produces the lines because they now match the defaults. Yes, I understand. Is there some policy here, for instance to keep those in, for clarity? > > @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m > > CONFIG_I2C_AT91=y > > CONFIG_I2C_IMX=y > > CONFIG_I2C_MV64XXX=y > > -CONFIG_I2C_NOMADIK=y > > CONFIG_SPI=y > > CONFIG_SPI_ATMEL=y > > CONFIG_SPI_IMX=y > > This one is still there. Not sure why it's no longer enabled. It's not in the current .config. From what I can see, it depends on ARCH_AMBA, which is selected by ARCH_NOMADIK, but that one is not enabled by multi_v5_defconfig. Not sure if that is an oversight, or a change, a the dependency is bogus, or something else. If you find that useful, I can try to find those dependency chains for the other options, but I definitely lack the knowledge about the history of those old platforms, so I can't reason about them. But I could present you the findings and you can then say what to do? > > CONFIG_REGULATOR_FIXED_VOLTAGE=y > > CONFIG_MEDIA_SUPPORT=y > > CONFIG_MEDIA_CAMERA_SUPPORT=y > > -CONFIG_V4L_PLATFORM_DRIVERS=y > > -CONFIG_VIDEO_ASPEED=m > > -CONFIG_VIDEO_ATMEL_ISI=m > > CONFIG_DRM=y > > CONFIG_DRM_ATMEL_HLCDC=m > > -CONFIG_DRM_PANEL_SIMPLE=y > > -CONFIG_DRM_PANEL_EDP=y > > CONFIG_DRM_ASPEED_GFX=m > > -CONFIG_FB_IMX=y > > -CONFIG_FB_ATMEL=y > > -CONFIG_BACKLIGHT_ATMEL_LCDC=y > > This doesn't look right at all. If you want to disable graphics support, > please do that in a separate patch and explain why we can't have those > any more. Are you running into problems with the vmlinux size? As I mentioned, the .config didn't change at all, so those options are already not included in mainline anymore. AFAICS, those last options depend on CONFIG_FB, which isn't enabled. Is that a regression due to the recent fbdev changes? Cheers, Andre > > > CONFIG_LIBCRC32C=y > > CONFIG_DEBUG_INFO=y > > -CONFIG_DEBUG_FS=y > > CONFIG_MAGIC_SYSRQ=y > > +CONFIG_DEBUG_FS=y > > CONFIG_DEBUG_KERNEL=y > > # CONFIG_SCHED_DEBUG is not set > > # CONFIG_DEBUG_PREEMPT is not set > > This should probably go along with the ZBOOT_ROM change, it's > only cosmetic. > > Arnd
On Tue, Mar 8, 2022 at 1:07 PM Andre Przywara <andre.przywara@arm.com> wrote: > On Tue, 8 Mar 2022 10:38:37 +0100 Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Mar 7, 2022 at 3:34 PM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > Some Kconfig options have changed, some other platforms have been > > > removed. > > > > Please split this up into logical chunks: list the platforms that were removed > > and remove only the lines corresponding to those platforms in one patch, > > do functional changes in separate patches each with a reason for doing them, > > and cleanups (moving lines to match the savedefconfig output, removing lines > > that are now the default) in one final patch. > > Actually this patch is meant to be only about the last past: to sync > multi_v5_defconfig with the output of "make savedefconfig". .config stays > the same. I initially tried to chase down the reason for each line change, > but gave up quickly, because it becomes tedious to learn about this, > especially about symbols that got *removed*. Also Kconfig is somewhat > sensitive, a single "select" or "default" change in one random Kconfig can > affect the result of savedefconfig. > > As I noted in the commit message, the .config does *not* change as a result > of this patch, the whole purpose is just to make the next patch clearer. Ok, then just change the symbols that move around, not the ones that may have gone missing unintentionally. > So I can try find the reason for each removal, if you like, but I am not > sure that's worthwhile? It is my understanding that Kconfig changes tend > to accumulate cruft in the various defconfigs over time. In U-Boot we gave > up on reasoning, and just regularly sync the output of savedefconfig over > to the *_defconfigs, to keep them minimal and meaningful. > > And I found Olof's commit 30b10c77837c ("ARM: defconfig: re-run > savedefconfig on multi_v* configs") as a precedence for this kind of cleanup. I know, but I never liked doing this because it hides regressions. > > > CONFIG_AEABI=y > > > CONFIG_HIGHMEM=y > > > -CONFIG_ZBOOT_ROM_TEXT=0x0 > > > -CONFIG_ZBOOT_ROM_BSS=0x0 > > > CONFIG_ARM_APPENDED_DTB=y > > > CONFIG_ARM_ATAG_DTB_COMPAT=y > > > CONFIG_CPU_FREQ=y > > > > These were not removed, what happened here is that 'savedefconfig' > > no longer produces the lines because they now match the defaults. > > Yes, I understand. Is there some policy here, for instance to keep > those in, for clarity? In this case, as with the moving lines around, there is no functional change at all, and doing the same thing on older kernels will still result in the same behavior. I'm not worried about those at all, so just put them all into one patch. > > > @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m > > > CONFIG_I2C_AT91=y > > > CONFIG_I2C_IMX=y > > > CONFIG_I2C_MV64XXX=y > > > -CONFIG_I2C_NOMADIK=y > > > CONFIG_SPI=y > > > CONFIG_SPI_ATMEL=y > > > CONFIG_SPI_IMX=y > > > > This one is still there. Not sure why it's no longer enabled. > > It's not in the current .config. From what I can see, it depends on > ARCH_AMBA, which is selected by ARCH_NOMADIK, but that one is not enabled > by multi_v5_defconfig. Not sure if that is an oversight, or a change, a > the dependency is bogus, or something else. > > If you find that useful, I can try to find those dependency chains for the > other options, but I definitely lack the knowledge about the history of > those old platforms, so I can't reason about them. But I could present you > the findings and you can then say what to do? I see this was the result of 66e0c12f9e17 ("ARM: nomadik: switch to use the Nomadik I2C driver"). It's ok to remove this line and others like it, just explain what happened for these, as the driver is still enabled. > > > CONFIG_REGULATOR_FIXED_VOLTAGE=y > > > CONFIG_MEDIA_SUPPORT=y > > > CONFIG_MEDIA_CAMERA_SUPPORT=y > > > -CONFIG_V4L_PLATFORM_DRIVERS=y > > > -CONFIG_VIDEO_ASPEED=m > > > -CONFIG_VIDEO_ATMEL_ISI=m > > > CONFIG_DRM=y > > > CONFIG_DRM_ATMEL_HLCDC=m > > > -CONFIG_DRM_PANEL_SIMPLE=y > > > -CONFIG_DRM_PANEL_EDP=y > > > CONFIG_DRM_ASPEED_GFX=m > > > -CONFIG_FB_IMX=y > > > -CONFIG_FB_ATMEL=y > > > -CONFIG_BACKLIGHT_ATMEL_LCDC=y > > > > This doesn't look right at all. If you want to disable graphics support, > > please do that in a separate patch and explain why we can't have those > > any more. Are you running into problems with the vmlinux size? > > As I mentioned, the .config didn't change at all, so those options are > already not included in mainline anymore. > > AFAICS, those last options depend on CONFIG_FB, which isn't enabled. Is > that a regression due to the recent fbdev changes? Correct, this part was clearly unintentional, and I don't ever want to see a patch to remove lines like these with a changelog text that fails to explain why we want them to be removed. We clearly have platforms that are enabled in multi_v5_config that use some of those drivers, and we had users that wanted them to be enabled. I think there are three separate issues here: FB_IMX and FB_ATMEL broke because of f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB"), VIDEO_ASPEED and VIDEO_ATMEL_ISI broke during b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filtering"), and PANEL_EDP was introduced in 310720875efa ("ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_EDP") without the option ever making it in [1]. These are all bugs that need to be addressed individually, and not just in a single defconfig file but across all the affected platforms. Arnd [1] https://lore.kernel.org/all/CAD=FV=VbYcdSqxLHdSaDPh=X0hbW6VWV0mM-iFy3k0J1q+6MWg@mail.gmail.com/
On Tue, Mar 8, 2022 at 1:07 PM Andre Przywara <andre.przywara@arm.com> wrote: > If you find that useful, I can try to find those dependency chains for the > other options, but I definitely lack the knowledge about the history of > those old platforms, so I can't reason about them. But I could present you > the findings and you can then say what to do? Back to this point: the most interesting ones are those that broke because of some added dependency, or an option that got renamed. This is what I would use to find the root cause in a scripted way (after identifying the last "good" version): $ git bisect run bash -c "make -s O=obj-arm ARCH=arm multi_v5_defconfig && grep CONFIG_DRM_PANEL_SIMPLE obj-arm/.config" You can group the ones that went away because of a deleted platform or driver, or those that are just default-enabled now, but for cases that no longer use a driver that may be needed by some platform, just having the information about what patch broke them usually tells us what happened. We still need to decide on an appropriate action then, which could be to include the new dependency explicitly, or to remove the entire platform that used the driver because we find that the maintainers never noticed it breaking. Arnd
On 08/03/2022 at 13:07, Andre Przywara wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Tue, 8 Mar 2022 10:38:37 +0100 > Arnd Bergmann <arnd@arndb.de> wrote: > > Hi Arnd, > > thanks for having a look. I was a bit unsure about the policy of those > changes, so glad to have the discussion. > >> On Mon, Mar 7, 2022 at 3:34 PM Andre Przywara <andre.przywara@arm.com> wrote: >>> >>> Some Kconfig options have changed, some other platforms have been >>> removed. >> >> Please split this up into logical chunks: list the platforms that were removed >> and remove only the lines corresponding to those platforms in one patch, >> do functional changes in separate patches each with a reason for doing them, >> and cleanups (moving lines to match the savedefconfig output, removing lines >> that are now the default) in one final patch. > > Actually this patch is meant to be only about the last past: to sync > multi_v5_defconfig with the output of "make savedefconfig". .config stays > the same. I initially tried to chase down the reason for each line change, > but gave up quickly, because it becomes tedious to learn about this, > especially about symbols that got *removed*. Also Kconfig is somewhat > sensitive, a single "select" or "default" change in one random Kconfig can > affect the result of savedefconfig. > > As I noted in the commit message, the .config does *not* change as a result > of this patch, the whole purpose is just to make the next patch clearer. > > So I can try find the reason for each removal, if you like, but I am not > sure that's worthwhile? It is my understanding that Kconfig changes tend > to accumulate cruft in the various defconfigs over time. In U-Boot we gave > up on reasoning, and just regularly sync the output of savedefconfig over > to the *_defconfigs, to keep them minimal and meaningful. > > And I found Olof's commit 30b10c77837c ("ARM: defconfig: re-run > savedefconfig on multi_v* configs") as a precedence for this kind of cleanup. > >>> CONFIG_AEABI=y >>> CONFIG_HIGHMEM=y >>> -CONFIG_ZBOOT_ROM_TEXT=0x0 >>> -CONFIG_ZBOOT_ROM_BSS=0x0 >>> CONFIG_ARM_APPENDED_DTB=y >>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>> CONFIG_CPU_FREQ=y >> >> These were not removed, what happened here is that 'savedefconfig' >> no longer produces the lines because they now match the defaults. > > Yes, I understand. Is there some policy here, for instance to keep > those in, for clarity? > >>> @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m >>> CONFIG_I2C_AT91=y >>> CONFIG_I2C_IMX=y >>> CONFIG_I2C_MV64XXX=y >>> -CONFIG_I2C_NOMADIK=y >>> CONFIG_SPI=y >>> CONFIG_SPI_ATMEL=y >>> CONFIG_SPI_IMX=y >> >> This one is still there. Not sure why it's no longer enabled. > > It's not in the current .config. From what I can see, it depends on > ARCH_AMBA, which is selected by ARCH_NOMADIK, but that one is not enabled > by multi_v5_defconfig. Not sure if that is an oversight, or a change, a > the dependency is bogus, or something else. > > If you find that useful, I can try to find those dependency chains for the > other options, but I definitely lack the knowledge about the history of > those old platforms, so I can't reason about them. But I could present you > the findings and you can then say what to do? > >>> CONFIG_REGULATOR_FIXED_VOLTAGE=y >>> CONFIG_MEDIA_SUPPORT=y >>> CONFIG_MEDIA_CAMERA_SUPPORT=y >>> -CONFIG_V4L_PLATFORM_DRIVERS=y >>> -CONFIG_VIDEO_ASPEED=m >>> -CONFIG_VIDEO_ATMEL_ISI=m >>> CONFIG_DRM=y >>> CONFIG_DRM_ATMEL_HLCDC=m >>> -CONFIG_DRM_PANEL_SIMPLE=y >>> -CONFIG_DRM_PANEL_EDP=y >>> CONFIG_DRM_ASPEED_GFX=m >>> -CONFIG_FB_IMX=y >>> -CONFIG_FB_ATMEL=y >>> -CONFIG_BACKLIGHT_ATMEL_LCDC=y >> >> This doesn't look right at all. If you want to disable graphics support, >> please do that in a separate patch and explain why we can't have those >> any more. Are you running into problems with the vmlinux size? > > As I mentioned, the .config didn't change at all, so those options are > already not included in mainline anymore. As far as I'm concerned and only talking about the drivers, I would prefer that we keep the following config options activated in the .config: CONFIG_VIDEO_ATMEL_ISI=m CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB_ATMEL=y CONFIG_BACKLIGHT_ATMEL_LCDC=y The question to know if they are activated by default or not and if the associated stack is selected or not, well... I lost track of this, sorry. Regards, Nicolas > AFAICS, those last options depend on CONFIG_FB, which isn't enabled. Is > that a regression due to the recent fbdev changes? > > Cheers, > Andre > >> >>> CONFIG_LIBCRC32C=y >>> CONFIG_DEBUG_INFO=y >>> -CONFIG_DEBUG_FS=y >>> CONFIG_MAGIC_SYSRQ=y >>> +CONFIG_DEBUG_FS=y >>> CONFIG_DEBUG_KERNEL=y >>> # CONFIG_SCHED_DEBUG is not set >>> # CONFIG_DEBUG_PREEMPT is not set >> >> This should probably go along with the ZBOOT_ROM change, it's >> only cosmetic. >> >> Arnd > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 8, 2022 at 3:30 PM Nicolas Ferre <nicolas.ferre@microchip.com> wrote: > On 08/03/2022 at 13:07, Andre Przywara wrote: > > As far as I'm concerned and only talking about the drivers, I would > prefer that we keep the following config options activated in the .config: > > CONFIG_VIDEO_ATMEL_ISI=m > CONFIG_DRM_PANEL_SIMPLE=y > CONFIG_FB_ATMEL=y > CONFIG_BACKLIGHT_ATMEL_LCDC=y > > The question to know if they are activated by default or not and if the > associated stack is selected or not, well... I lost track of this, sorry. These are actually missing, I think the two options we need to enable are: CONFIG_MEDIA_PLATFORM_SUPPORT=y CONFIG_FB=y All the other options that get removed are either now the default, or are no longer part of the kernel. Arnd
On Tue, 8 Mar 2022 10:38:37 +0100 Arnd Bergmann <arnd@arndb.de> wrote: Hi, > On Mon, Mar 7, 2022 at 3:34 PM Andre Przywara <andre.przywara@arm.com> wrote: > > > > Some Kconfig options have changed, some other platforms have been > > removed. > > Please split this up into logical chunks: list the platforms that were removed > and remove only the lines corresponding to those platforms in one patch, > do functional changes in separate patches each with a reason for doing them, > and cleanups (moving lines to match the savedefconfig output, removing lines > that are now the default) in one final patch. OK, I did that, and will send that as a separate series, as it's not really related to the F1C100 DT changes. Please disregard patches 13/14 and 14/14 for now. For the sake of completeness of this thread, this is what I found out: > > > CONFIG_AEABI=y > > CONFIG_HIGHMEM=y > > -CONFIG_ZBOOT_ROM_TEXT=0x0 > > -CONFIG_ZBOOT_ROM_BSS=0x0 > > CONFIG_ARM_APPENDED_DTB=y > > CONFIG_ARM_ATAG_DTB_COMPAT=y > > CONFIG_CPU_FREQ=y > > These were not removed, what happened here is that 'savedefconfig' > no longer produces the lines because they now match the defaults. > > > @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m > > CONFIG_I2C_AT91=y > > CONFIG_I2C_IMX=y > > CONFIG_I2C_MV64XXX=y > > -CONFIG_I2C_NOMADIK=y > > CONFIG_SPI=y > > CONFIG_SPI_ATMEL=y > > CONFIG_SPI_IMX=y > > This one is still there. Not sure why it's no longer enabled. ARCH_U300 was the only user, and we lost a prerequisite (ARCH_AMBA) when it was removed, so this symbol cannot be selected anymore. > > > CONFIG_REGULATOR_FIXED_VOLTAGE=y > > CONFIG_MEDIA_SUPPORT=y > > CONFIG_MEDIA_CAMERA_SUPPORT=y > > -CONFIG_V4L_PLATFORM_DRIVERS=y > > -CONFIG_VIDEO_ASPEED=m > > -CONFIG_VIDEO_ATMEL_ISI=m > > CONFIG_DRM=y > > CONFIG_DRM_ATMEL_HLCDC=m > > -CONFIG_DRM_PANEL_SIMPLE=y > > -CONFIG_DRM_PANEL_EDP=y > > CONFIG_DRM_ASPEED_GFX=m > > -CONFIG_FB_IMX=y > > -CONFIG_FB_ATMEL=y > > -CONFIG_BACKLIGHT_ATMEL_LCDC=y > > This doesn't look right at all. If you want to disable graphics support, > please do that in a separate patch and explain why we can't have those > any more. Are you running into problems with the vmlinux size? CONFIG_FB was not selected anymore, when DRM_KMS_FB_HELPER was removed, so we lost all those drivers. I brought CONFIG_FB in explicitly, as multi_v7_defconfig did a while ago. More details in the commit messages of the upcoming series. Cheers, Andre > > CONFIG_LIBCRC32C=y > > CONFIG_DEBUG_INFO=y > > -CONFIG_DEBUG_FS=y > > CONFIG_MAGIC_SYSRQ=y > > +CONFIG_DEBUG_FS=y > > CONFIG_DEBUG_KERNEL=y > > # CONFIG_SCHED_DEBUG is not set > > # CONFIG_DEBUG_PREEMPT is not set > > This should probably go along with the ZBOOT_ROM change, it's > only cosmetic. > > Arnd
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig index fe8d760256a4..8b7fe7ff5366 100644 --- a/arch/arm/configs/multi_v5_defconfig +++ b/arch/arm/configs/multi_v5_defconfig @@ -24,11 +24,6 @@ CONFIG_MACH_DM355_LEOPARD=y CONFIG_MACH_MITYOMAPL138=y CONFIG_MACH_OMAPL138_HAWKBOARD=y CONFIG_ARCH_MXC=y -CONFIG_MACH_MX21ADS=y -CONFIG_MACH_MX27ADS=y -CONFIG_MACH_MX27_3DS=y -CONFIG_MACH_IMX27_VISSTRIM_M10=y -CONFIG_MACH_PCA100=y CONFIG_SOC_IMX25=y CONFIG_SOC_IMX27=y CONFIG_ARCH_MVEBU=y @@ -57,11 +52,8 @@ CONFIG_MACH_WNR854T=y CONFIG_MACH_RD88F5181L_GE=y CONFIG_MACH_RD88F5181L_FXO=y CONFIG_MACH_RD88F6183AP_GE=y -CONFIG_ARCH_U300=y CONFIG_AEABI=y CONFIG_HIGHMEM=y -CONFIG_ZBOOT_ROM_TEXT=0x0 -CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CPU_FREQ=y @@ -159,7 +151,6 @@ CONFIG_I2C_ASPEED=m CONFIG_I2C_AT91=y CONFIG_I2C_IMX=y CONFIG_I2C_MV64XXX=y -CONFIG_I2C_NOMADIK=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y CONFIG_SPI_IMX=y @@ -183,22 +174,13 @@ CONFIG_ORION_WATCHDOG=y CONFIG_NPCM7XX_WATCHDOG=y CONFIG_IMX2_WDT=y CONFIG_MFD_ATMEL_HLCDC=y -# CONFIG_ABX500_CORE is not set CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_MEDIA_SUPPORT=y CONFIG_MEDIA_CAMERA_SUPPORT=y -CONFIG_V4L_PLATFORM_DRIVERS=y -CONFIG_VIDEO_ASPEED=m -CONFIG_VIDEO_ATMEL_ISI=m CONFIG_DRM=y CONFIG_DRM_ATMEL_HLCDC=m -CONFIG_DRM_PANEL_SIMPLE=y -CONFIG_DRM_PANEL_EDP=y CONFIG_DRM_ASPEED_GFX=m -CONFIG_FB_IMX=y -CONFIG_FB_ATMEL=y -CONFIG_BACKLIGHT_ATMEL_LCDC=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y @@ -303,8 +285,8 @@ CONFIG_CRYPTO_DEV_MARVELL_CESA=y CONFIG_CRC_CCITT=y CONFIG_LIBCRC32C=y CONFIG_DEBUG_INFO=y -CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_FS=y CONFIG_DEBUG_KERNEL=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set
Some Kconfig options have changed, some other platforms have been removed. Update multi_v5_defconfig with the result of "make savedefconfig", the resulting .config files are identical. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- arch/arm/configs/multi_v5_defconfig | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-)