| Message ID | 20230125230823.1567778-1-trini@konsulko.com |
|---|---|
| State | Accepted |
| Commit | 007ae5d108a37564905ea1588cb279f3a522cc3d |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | lmb: Default to not-LMB_USE_MAX_REGIONS | expand |
On Wed, Jan 25, 2023 at 06:08:23PM -0500, Tom Rini wrote: > The LMB code allows for picking a hard limit on the number of regions it > can know of, or to dynamically allocate these regions. The reason for > this choice is to allow for the compiler to perform a size optimization > in the common case. This optimization however, is very small, ranging > from 196 bytes to 15 bytes saved, or in some cases, being larger. Now > that we also have more regions covered by LMB (in order to protect > various parts of our self at run time), the default of 8 is also much > easier to hit and leads to non-obvious error messages (which imply that > an area is protected, not that we're out of areas to add to the list). > > Switch to the dynamic use as the default. > > Signed-off-by: Tom Rini <trini@konsulko.com> Applied to u-boot/master, thanks!
Hi Tom, We currently face an issue on our apalis-imx8 machine, that is not able to boot with a ramdisk. What happens is that there are all 8 of 8 LMBs reserved and fdt tries to allocate one more, probably for relocation. I now stumbled on this recent patch and noticed that in my understanding this is introducing a regression to all the boards you remove `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? For the other question this raises to me is it in general safe to just increase this limit, let's say to 16? And since it was quite an effort debugging this issue I thought of adding a debug print if the MAX cnt in lmb.c is being hit to ease that pain for other devs, would you be fine with something like this? Thanks in advance for your answers, Philippe On Wed, 2023-01-25 at 18:08 -0500, Tom Rini wrote: > The LMB code allows for picking a hard limit on the number of regions > it > can know of, or to dynamically allocate these regions. The reason for > this choice is to allow for the compiler to perform a size > optimization > in the common case. This optimization however, is very small, ranging > from 196 bytes to 15 bytes saved, or in some cases, being larger. Now > that we also have more regions covered by LMB (in order to protect > various parts of our self at run time), the default of 8 is also much > easier to hit and leads to non-obvious error messages (which imply > that > an area is protected, not that we're out of areas to add to the list). > > Switch to the dynamic use as the default. > > Signed-off-by: Tom Rini <trini@konsulko.com> > --- > configs/a3y17lte_defconfig | 1 - > configs/a5y17lte_defconfig | 1 - > configs/a7y17lte_defconfig | 1 - > configs/dragonboard845c_defconfig | 1 - > configs/mt7981_emmc_rfb_defconfig | 1 - > configs/mt7981_rfb_defconfig | 1 - > configs/mt7981_sd_rfb_defconfig | 1 - > configs/mt7986_rfb_defconfig | 1 - > configs/mt7986a_bpir3_emmc_defconfig | 1 - > configs/mt7986a_bpir3_sd_defconfig | 1 - > configs/qcs404evb_defconfig | 1 - > configs/starqltechn_defconfig | 1 - > lib/Kconfig | 1 - > 13 files changed, 13 deletions(-) > > diff --git a/configs/a3y17lte_defconfig b/configs/a3y17lte_defconfig > index 124fb8d47617..0215c5f234bb 100644 > --- a/configs/a3y17lte_defconfig > +++ b/configs/a3y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/a5y17lte_defconfig b/configs/a5y17lte_defconfig > index ffb0b3f474a6..d1cd97baf512 100644 > --- a/configs/a5y17lte_defconfig > +++ b/configs/a5y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/a7y17lte_defconfig b/configs/a7y17lte_defconfig > index 8c1229d8d5ec..bef2d0945aec 100644 > --- a/configs/a7y17lte_defconfig > +++ b/configs/a7y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/dragonboard845c_defconfig > b/configs/dragonboard845c_defconfig > index a69d82761a8d..cef82f56108e 100644 > --- a/configs/dragonboard845c_defconfig > +++ b/configs/dragonboard845c_defconfig > @@ -26,4 +26,3 @@ CONFIG_DM_PMIC=y > CONFIG_PMIC_QCOM=y > CONFIG_MSM_GENI_SERIAL=y > CONFIG_SPMI_MSM=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_emmc_rfb_defconfig > b/configs/mt7981_emmc_rfb_defconfig > index b3b37b6e5ed4..4832a2264395 100644 > --- a/configs/mt7981_emmc_rfb_defconfig > +++ b/configs/mt7981_emmc_rfb_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_rfb_defconfig > b/configs/mt7981_rfb_defconfig > index b7ffb4dfa74d..c3975278871e 100644 > --- a/configs/mt7981_rfb_defconfig > +++ b/configs/mt7981_rfb_defconfig > @@ -64,4 +64,3 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_MTK_SPIM=y > CONFIG_HEXDUMP=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_sd_rfb_defconfig > b/configs/mt7981_sd_rfb_defconfig > index 85be9bbc5030..17592dc22b9a 100644 > --- a/configs/mt7981_sd_rfb_defconfig > +++ b/configs/mt7981_sd_rfb_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7986_rfb_defconfig > b/configs/mt7986_rfb_defconfig > index ac91c93efb42..1363f9dc6d0b 100644 > --- a/configs/mt7986_rfb_defconfig > +++ b/configs/mt7986_rfb_defconfig > @@ -64,4 +64,3 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_MTK_SPIM=y > CONFIG_HEXDUMP=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7986a_bpir3_emmc_defconfig > b/configs/mt7986a_bpir3_emmc_defconfig > index 2d4876f299f4..354159df9b2e 100644 > --- a/configs/mt7986a_bpir3_emmc_defconfig > +++ b/configs/mt7986a_bpir3_emmc_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7986a_bpir3_sd_defconfig > b/configs/mt7986a_bpir3_sd_defconfig > index 08edfe7ac409..db7ef98d807b 100644 > --- a/configs/mt7986a_bpir3_sd_defconfig > +++ b/configs/mt7986a_bpir3_sd_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/qcs404evb_defconfig b/configs/qcs404evb_defconfig > index dae155141152..d3608cae9f90 100644 > --- a/configs/qcs404evb_defconfig > +++ b/configs/qcs404evb_defconfig > @@ -51,4 +51,3 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_DWC3=y > CONFIG_USB_DWC3_GENERIC=y > CONFIG_USB_STORAGE=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/starqltechn_defconfig > b/configs/starqltechn_defconfig > index 7a64f2a7a088..81fd7b22676e 100644 > --- a/configs/starqltechn_defconfig > +++ b/configs/starqltechn_defconfig > @@ -33,4 +33,3 @@ CONFIG_VIDEO=y > CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_VIDEO_SIMPLE=y > CONFIG_VIDEO_DT_SIMPLEFB=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/lib/Kconfig b/lib/Kconfig > index 549bd3577851..59e4304afd1a 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -1028,7 +1028,6 @@ config LMB > config LMB_USE_MAX_REGIONS > bool "Use a common number of memory and reserved regions in > lmb lib" > depends on LMB > - default y > help > Define the number of supported memory regions in the library > logical > memory blocks.
On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote: > Hi Tom, > > We currently face an issue on our apalis-imx8 machine, that is not able > to boot with a ramdisk. What happens is that there are all 8 of 8 LMBs > reserved and fdt tries to allocate one more, probably for relocation. > > I now stumbled on this recent patch and noticed that in my understanding > this is introducing a regression to all the boards you remove > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > For the other question this raises to me is it in general safe to just > increase this limit, let's say to 16? > > And since it was quite an effort debugging this issue I thought of > adding a debug print if the MAX cnt in lmb.c is being hit to ease that > pain for other devs, would you be fine with something like this? Right, so with the late in the cycle change to make EFI use LMBs as well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The change here switches from a static allocation of a maximum number of LMBs to dynamically allocating as many of them as needed.
On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: > On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote: > > > Hi Tom, > > > > We currently face an issue on our apalis-imx8 machine, that is not > > able > > to boot with a ramdisk. What happens is that there are all 8 of 8 > > LMBs > > reserved and fdt tries to allocate one more, probably for > > relocation. > > > > I now stumbled on this recent patch and noticed that in my > > understanding > > this is introducing a regression to all the boards you remove > > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > > > For the other question this raises to me is it in general safe to > > just > > increase this limit, let's say to 16? > > > > And since it was quite an effort debugging this issue I thought of > > adding a debug print if the MAX cnt in lmb.c is being hit to ease > > that > > pain for other devs, would you be fine with something like this? > > Right, so with the late in the cycle change to make EFI use LMBs as > well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The > change here switches from a static allocation of a maximum number of > LMBs to dynamically allocating as many of them as needed. But since you no longer enable LMB_USE_MAX_REGIONS then theres the two limits (default=8) LMB_MEMORY_REGIONS=8 LMB_RESERVED_REGIONS=8 that are limiting the maximum LMB numbers. So in my view this commit does create a regression for all boards you delete `CONFIG_LMB_MAX_REGIONS=64`. At least for me rgn->max is still set to 8 and also after this commit I hit that limit. [1] [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288
On Wed, Feb 08, 2023 at 03:13:31PM +0000, Philippe Schenker wrote: > On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: > > On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote: > > > > > Hi Tom, > > > > > > We currently face an issue on our apalis-imx8 machine, that is not > > > able > > > to boot with a ramdisk. What happens is that there are all 8 of 8 > > > LMBs > > > reserved and fdt tries to allocate one more, probably for > > > relocation. > > > > > > I now stumbled on this recent patch and noticed that in my > > > understanding > > > this is introducing a regression to all the boards you remove > > > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > > > > > For the other question this raises to me is it in general safe to > > > just > > > increase this limit, let's say to 16? > > > > > > And since it was quite an effort debugging this issue I thought of > > > adding a debug print if the MAX cnt in lmb.c is being hit to ease > > > that > > > pain for other devs, would you be fine with something like this? > > > > Right, so with the late in the cycle change to make EFI use LMBs as > > well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The > > change here switches from a static allocation of a maximum number of > > LMBs to dynamically allocating as many of them as needed. > > > But since you no longer enable LMB_USE_MAX_REGIONS then theres the two > limits (default=8) > > LMB_MEMORY_REGIONS=8 > LMB_RESERVED_REGIONS=8 > > that are limiting the maximum LMB numbers. So in my view this commit > does create a regression for all boards you delete > `CONFIG_LMB_MAX_REGIONS=64`. > > At least for me rgn->max is still set to 8 and also after this commit I > hit that limit. [1] > > [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288 Ugh, you're right and I missed what this ended up doing, thanks for explaining it. I'll go revert my commit shortly and pick up one of the ones that raised the default.
On 2/8/23 16:16, Tom Rini wrote: > On Wed, Feb 08, 2023 at 03:13:31PM +0000, Philippe Schenker wrote: >> On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: >>> On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote: >>> >>>> Hi Tom, >>>> >>>> We currently face an issue on our apalis-imx8 machine, that is not >>>> able >>>> to boot with a ramdisk. What happens is that there are all 8 of 8 >>>> LMBs >>>> reserved and fdt tries to allocate one more, probably for >>>> relocation. >>>> >>>> I now stumbled on this recent patch and noticed that in my >>>> understanding >>>> this is introducing a regression to all the boards you remove >>>> `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? >>>> >>>> For the other question this raises to me is it in general safe to >>>> just >>>> increase this limit, let's say to 16? >>>> >>>> And since it was quite an effort debugging this issue I thought of >>>> adding a debug print if the MAX cnt in lmb.c is being hit to ease >>>> that >>>> pain for other devs, would you be fine with something like this? >>> Right, so with the late in the cycle change to make EFI use LMBs as >>> well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The >>> change here switches from a static allocation of a maximum number of >>> LMBs to dynamically allocating as many of them as needed. >> >> But since you no longer enable LMB_USE_MAX_REGIONS then theres the two >> limits (default=8) >> >> LMB_MEMORY_REGIONS=8 >> LMB_RESERVED_REGIONS=8 >> >> that are limiting the maximum LMB numbers. So in my view this commit >> does create a regression for all boards you delete >> `CONFIG_LMB_MAX_REGIONS=64`. >> >> At least for me rgn->max is still set to 8 and also after this commit I >> hit that limit. [1] >> >> [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288 > Ugh, you're right and I missed what this ended up doing, thanks for > explaining it. I'll go revert my commit shortly and pick up one of the > ones that raised the default. Hi, only for reference, with new LMB management config LMB_USE_MAX_REGIONS bool "Use a common number of memory and reserved regions in lmb lib" depends on LMB - default y The correct patch without regression is for each board -CONFIG_LMB_MAX_REGIONS=64 +CONFIG_LMB_RESERVED_REGIONS=64 See https://lore.kernel.org/all/20210310091632.17103-1-patrick.delaunay@foss.st.com/ Patrick
diff --git a/configs/a3y17lte_defconfig b/configs/a3y17lte_defconfig index 124fb8d47617..0215c5f234bb 100644 --- a/configs/a3y17lte_defconfig +++ b/configs/a3y17lte_defconfig @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/a5y17lte_defconfig b/configs/a5y17lte_defconfig index ffb0b3f474a6..d1cd97baf512 100644 --- a/configs/a5y17lte_defconfig +++ b/configs/a5y17lte_defconfig @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/a7y17lte_defconfig b/configs/a7y17lte_defconfig index 8c1229d8d5ec..bef2d0945aec 100644 --- a/configs/a7y17lte_defconfig +++ b/configs/a7y17lte_defconfig @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x2000000 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/dragonboard845c_defconfig b/configs/dragonboard845c_defconfig index a69d82761a8d..cef82f56108e 100644 --- a/configs/dragonboard845c_defconfig +++ b/configs/dragonboard845c_defconfig @@ -26,4 +26,3 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_QCOM=y CONFIG_MSM_GENI_SERIAL=y CONFIG_SPMI_MSM=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_emmc_rfb_defconfig b/configs/mt7981_emmc_rfb_defconfig index b3b37b6e5ed4..4832a2264395 100644 --- a/configs/mt7981_emmc_rfb_defconfig +++ b/configs/mt7981_emmc_rfb_defconfig @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_rfb_defconfig b/configs/mt7981_rfb_defconfig index b7ffb4dfa74d..c3975278871e 100644 --- a/configs/mt7981_rfb_defconfig +++ b/configs/mt7981_rfb_defconfig @@ -64,4 +64,3 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_sd_rfb_defconfig b/configs/mt7981_sd_rfb_defconfig index 85be9bbc5030..17592dc22b9a 100644 --- a/configs/mt7981_sd_rfb_defconfig +++ b/configs/mt7981_sd_rfb_defconfig @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986_rfb_defconfig b/configs/mt7986_rfb_defconfig index ac91c93efb42..1363f9dc6d0b 100644 --- a/configs/mt7986_rfb_defconfig +++ b/configs/mt7986_rfb_defconfig @@ -64,4 +64,3 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_emmc_defconfig b/configs/mt7986a_bpir3_emmc_defconfig index 2d4876f299f4..354159df9b2e 100644 --- a/configs/mt7986a_bpir3_emmc_defconfig +++ b/configs/mt7986a_bpir3_emmc_defconfig @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_sd_defconfig b/configs/mt7986a_bpir3_sd_defconfig index 08edfe7ac409..db7ef98d807b 100644 --- a/configs/mt7986a_bpir3_sd_defconfig +++ b/configs/mt7986a_bpir3_sd_defconfig @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/qcs404evb_defconfig b/configs/qcs404evb_defconfig index dae155141152..d3608cae9f90 100644 --- a/configs/qcs404evb_defconfig +++ b/configs/qcs404evb_defconfig @@ -51,4 +51,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_STORAGE=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/starqltechn_defconfig b/configs/starqltechn_defconfig index 7a64f2a7a088..81fd7b22676e 100644 --- a/configs/starqltechn_defconfig +++ b/configs/starqltechn_defconfig @@ -33,4 +33,3 @@ CONFIG_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_VIDEO_SIMPLE=y CONFIG_VIDEO_DT_SIMPLEFB=y -CONFIG_LMB_MAX_REGIONS=64 diff --git a/lib/Kconfig b/lib/Kconfig index 549bd3577851..59e4304afd1a 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -1028,7 +1028,6 @@ config LMB config LMB_USE_MAX_REGIONS bool "Use a common number of memory and reserved regions in lmb lib" depends on LMB - default y help Define the number of supported memory regions in the library logical memory blocks.
The LMB code allows for picking a hard limit on the number of regions it can know of, or to dynamically allocate these regions. The reason for this choice is to allow for the compiler to perform a size optimization in the common case. This optimization however, is very small, ranging from 196 bytes to 15 bytes saved, or in some cases, being larger. Now that we also have more regions covered by LMB (in order to protect various parts of our self at run time), the default of 8 is also much easier to hit and leads to non-obvious error messages (which imply that an area is protected, not that we're out of areas to add to the list). Switch to the dynamic use as the default. Signed-off-by: Tom Rini <trini@konsulko.com> --- configs/a3y17lte_defconfig | 1 - configs/a5y17lte_defconfig | 1 - configs/a7y17lte_defconfig | 1 - configs/dragonboard845c_defconfig | 1 - configs/mt7981_emmc_rfb_defconfig | 1 - configs/mt7981_rfb_defconfig | 1 - configs/mt7981_sd_rfb_defconfig | 1 - configs/mt7986_rfb_defconfig | 1 - configs/mt7986a_bpir3_emmc_defconfig | 1 - configs/mt7986a_bpir3_sd_defconfig | 1 - configs/qcs404evb_defconfig | 1 - configs/starqltechn_defconfig | 1 - lib/Kconfig | 1 - 13 files changed, 13 deletions(-)