* [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu @ 2022-07-12 16:42 Florian Fainelli 2022-07-13 8:25 ` Arnd Bergmann 2022-09-08 11:04 ` Naresh Kamboju 0 siblings, 2 replies; 9+ messages in thread From: Florian Fainelli @ 2022-07-12 16:42 UTC (permalink / raw) To: linux-arm-kernel Cc: soc, bcm-kernel-feedback-list, william.zhang, krzysztof.kozlowski, anand.gore, arnd, olof, Florian Fainelli, Catalin Marinas, Will Deacon, open list There are now multiple Broadcom SoCs supported so group them under their own menu such that the selection is visually more appealing and we can easily add new platforms there in the future. This allows us to move ARCH_BRCMSTB back to its siblings. No functional changes introduced. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" arch/arm64/Kconfig.platforms | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 88ddc2e5b152..c8c15f611d4e 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -33,6 +33,11 @@ config ARCH_APPLE This enables support for Apple's in-house ARM SoC family, starting with the Apple M1. +menuconfig ARCH_BCM + bool "Broadcom SoC Support" + +if ARCH_BCM + config ARCH_BCM2835 bool "Broadcom BCM2835 family" select TIMER_OF @@ -72,6 +77,16 @@ config ARCH_BCMBCA This enables support for Broadcom BCA ARM-based broadband chipsets, including the DSL, PON and Wireless family of chips. +config ARCH_BRCMSTB + bool "Broadcom Set-Top-Box SoCs" + select ARCH_HAS_RESET_CONTROLLER + select GENERIC_IRQ_CHIP + select PINCTRL + help + This enables support for Broadcom's ARMv8 Set Top Box SoCs + +endif + config ARCH_BERLIN bool "Marvell Berlin SoC Family" select DW_APB_ICTL @@ -86,14 +101,6 @@ config ARCH_BITMAIN help This enables support for the Bitmain SoC Family. -config ARCH_BRCMSTB - bool "Broadcom Set-Top-Box SoCs" - select ARCH_HAS_RESET_CONTROLLER - select GENERIC_IRQ_CHIP - select PINCTRL - help - This enables support for Broadcom's ARMv8 Set Top Box SoCs - config ARCH_EXYNOS bool "ARMv8 based Samsung Exynos SoC family" select COMMON_CLK_SAMSUNG -- 2.25.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-12 16:42 [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu Florian Fainelli @ 2022-07-13 8:25 ` Arnd Bergmann 2022-07-13 8:40 ` Krzysztof Kozlowski 2022-09-08 11:04 ` Naresh Kamboju 1 sibling, 1 reply; 9+ messages in thread From: Arnd Bergmann @ 2022-07-13 8:25 UTC (permalink / raw) To: Florian Fainelli Cc: Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, Krzysztof Kozlowski, anand.gore, Arnd Bergmann, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > There are now multiple Broadcom SoCs supported so group them under their > own menu such that the selection is visually more appealing and we can > easily add new platforms there in the future. This allows us to move > ARCH_BRCMSTB back to its siblings. > > No functional changes introduced. > > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > --- > > Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" Hi Florian, So far, we have tried to keep the Kconfig.platforms file rather coarse-grained, mainly limiting it to company names and high-level families, but avoiding sub-menus or adding too many sub-families. If we add per-vendor submenus, we should probably first decide how we want to structure this across vendors. I've added maintainers and lists to Cc for a couple of the ones that are in a similar situation. I can see a couple of ways we can do this: a) keep the list of platforms as short as possible, combining related SoC families from a single vendor wherever possible, but no sub-menus (same as today) b) Always use sub-menus when there is more than one family, but keep relatively coarse platform selection. c) Use sub-menus and also move to a more fine-grained SoC selection, similar to what we have on 32-bit arm. I would not really want to go to c), but a) and b) both make sense to me as long as do it consistently across all platforms. Any other ideas or opinions? Arnd ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-13 8:25 ` Arnd Bergmann @ 2022-07-13 8:40 ` Krzysztof Kozlowski 2022-07-13 9:17 ` Geert Uytterhoeven 0 siblings, 1 reply; 9+ messages in thread From: Krzysztof Kozlowski @ 2022-07-13 8:40 UTC (permalink / raw) To: Arnd Bergmann, Florian Fainelli Cc: Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, anand.gore, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen On 13/07/2022 10:25, Arnd Bergmann wrote: > On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote: >> >> There are now multiple Broadcom SoCs supported so group them under their >> own menu such that the selection is visually more appealing and we can >> easily add new platforms there in the future. This allows us to move >> ARCH_BRCMSTB back to its siblings. >> >> No functional changes introduced. >> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> >> --- >> >> Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" > > Hi Florian, > > So far, we have tried to keep the Kconfig.platforms file rather coarse-grained, > mainly limiting it to company names and high-level families, but avoiding > sub-menus or adding too many sub-families. > > If we add per-vendor submenus, we should probably first decide how we > want to structure this across vendors. I've added maintainers and lists to > Cc for a couple of the ones that are in a similar situation. > > I can see a couple of ways we can do this: > > a) keep the list of platforms as short as possible, combining related > SoC families from a single vendor wherever possible, but no sub-menus > (same as today) > > b) Always use sub-menus when there is more than one family, but > keep relatively coarse platform selection. > > c) Use sub-menus and also move to a more fine-grained SoC > selection, similar to what we have on 32-bit arm. > > I would not really want to go to c), but a) and b) both make sense to > me as long as do it consistently across all platforms. > > Any other ideas or opinions? Whatever we decide here, the SoC can override in drivers/soc, just like Renesas did. I think Renesas chose option c), but made it in drivers/soc. I would vote to have consistent policy, so if arch/arm64 is a) or b), sub-archs should not redefine it in drivers/soc. Or we could choose d) d) keep arch/arm64 list of platforms as short as possible, but sub-archs can do whatever they like on drivers/soc. Personally, I find fine-grained SoC selection a bit ridiculous optimization, like compiling kernel, Glibc and userspace with -O3, -funroll-loops and many other flags. One gets smaller size but looses multi-platform and ability to test one kernel on different boards. Therefore I would vote for b) with disallowing drivers/soc defining more ARCH_ and more SOC_. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-13 8:40 ` Krzysztof Kozlowski @ 2022-07-13 9:17 ` Geert Uytterhoeven 2022-07-13 22:05 ` Florian Fainelli 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 2022-07-13 9:17 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Arnd Bergmann, Florian Fainelli, Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, anand.gore, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen Hi Krzysztof, On Wed, Jul 13, 2022 at 10:40 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 13/07/2022 10:25, Arnd Bergmann wrote: > > On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > >> There are now multiple Broadcom SoCs supported so group them under their > >> own menu such that the selection is visually more appealing and we can > >> easily add new platforms there in the future. This allows us to move > >> ARCH_BRCMSTB back to its siblings. > >> > >> No functional changes introduced. > >> > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > >> --- > >> > >> Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" > > > > Hi Florian, > > > > So far, we have tried to keep the Kconfig.platforms file rather coarse-grained, > > mainly limiting it to company names and high-level families, but avoiding > > sub-menus or adding too many sub-families. > > > > If we add per-vendor submenus, we should probably first decide how we > > want to structure this across vendors. I've added maintainers and lists to > > Cc for a couple of the ones that are in a similar situation. > > > > I can see a couple of ways we can do this: > > > > a) keep the list of platforms as short as possible, combining related > > SoC families from a single vendor wherever possible, but no sub-menus > > (same as today) > > > > b) Always use sub-menus when there is more than one family, but > > keep relatively coarse platform selection. > > > > c) Use sub-menus and also move to a more fine-grained SoC > > selection, similar to what we have on 32-bit arm. > > > > I would not really want to go to c), but a) and b) both make sense to > > me as long as do it consistently across all platforms. > > > > Any other ideas or opinions? > > Whatever we decide here, the SoC can override in drivers/soc, just like > Renesas did. I think Renesas chose option c), but made it in > drivers/soc. I would vote to have consistent policy, so if arch/arm64 is > a) or b), sub-archs should not redefine it in drivers/soc. We did so because of the "only a single symbol in arch/arm64/Kconfig.platforms"-policy. > Or we could choose d) > d) keep arch/arm64 list of platforms as short as possible, but sub-archs > can do whatever they like on drivers/soc. > > Personally, I find fine-grained SoC selection a bit ridiculous > optimization, like compiling kernel, Glibc and userspace with -O3, > -funroll-loops and many other flags. One gets smaller size but looses > multi-platform and ability to test one kernel on different boards. > Therefore I would vote for b) with disallowing drivers/soc defining more > ARCH_ and more SOC_. No one prevents you from selecting multiple SoCs, they are not mutually-exclusive... With arm64 (or risc-v ;-) instead of arm32 being used for all new SoCs, I expect the real small ones (with a few MiB of embedded SRAM) to enter the arm64 realm soon. No point in including e.g. all pinctrl drivers from the vendor if you have barely enough RAM to run Linux and your app... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-13 9:17 ` Geert Uytterhoeven @ 2022-07-13 22:05 ` Florian Fainelli 2022-08-15 17:15 ` Florian Fainelli 0 siblings, 1 reply; 9+ messages in thread From: Florian Fainelli @ 2022-07-13 22:05 UTC (permalink / raw) To: Geert Uytterhoeven, Krzysztof Kozlowski Cc: Arnd Bergmann, Florian Fainelli, Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, anand.gore, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen On 7/13/22 02:17, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Wed, Jul 13, 2022 at 10:40 AM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> On 13/07/2022 10:25, Arnd Bergmann wrote: >>> On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote: >>>> There are now multiple Broadcom SoCs supported so group them under their >>>> own menu such that the selection is visually more appealing and we can >>>> easily add new platforms there in the future. This allows us to move >>>> ARCH_BRCMSTB back to its siblings. >>>> >>>> No functional changes introduced. >>>> >>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> >>>> --- >>>> >>>> Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" >>> >>> Hi Florian, >>> >>> So far, we have tried to keep the Kconfig.platforms file rather coarse-grained, >>> mainly limiting it to company names and high-level families, but avoiding >>> sub-menus or adding too many sub-families. >>> >>> If we add per-vendor submenus, we should probably first decide how we >>> want to structure this across vendors. I've added maintainers and lists to >>> Cc for a couple of the ones that are in a similar situation. >>> >>> I can see a couple of ways we can do this: >>> >>> a) keep the list of platforms as short as possible, combining related >>> SoC families from a single vendor wherever possible, but no sub-menus >>> (same as today) >>> >>> b) Always use sub-menus when there is more than one family, but >>> keep relatively coarse platform selection. >>> >>> c) Use sub-menus and also move to a more fine-grained SoC >>> selection, similar to what we have on 32-bit arm. >>> >>> I would not really want to go to c), but a) and b) both make sense to >>> me as long as do it consistently across all platforms. >>> >>> Any other ideas or opinions? >> >> Whatever we decide here, the SoC can override in drivers/soc, just like >> Renesas did. I think Renesas chose option c), but made it in >> drivers/soc. I would vote to have consistent policy, so if arch/arm64 is >> a) or b), sub-archs should not redefine it in drivers/soc. > > We did so because of the "only a single symbol in > arch/arm64/Kconfig.platforms"-policy. I was not aware of that rule. It is a bit of a mixed situation with Broadcom SoCs but in essence, each Kconfig entry denotes a deeply different SoC architecture at the memory subsystem, bus, security or product space that you might not want to enable in your kernel. There is definitively sharing of drivers between all of the platforms and a lot of cross pollination too but usually these are deeply different that different kernel images do make sense. The itch that I wanted to calm was that ARCH_BRCMSTB was after the other Broadcom platforms separated by ARCH_BERLIN. if you prefer a pair of KConfig comments to delineate them and flatten the platform selection, that works for me, too. -- Florian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-13 22:05 ` Florian Fainelli @ 2022-08-15 17:15 ` Florian Fainelli 2022-08-15 19:52 ` Arnd Bergmann 0 siblings, 1 reply; 9+ messages in thread From: Florian Fainelli @ 2022-08-15 17:15 UTC (permalink / raw) To: Florian Fainelli, Geert Uytterhoeven, Krzysztof Kozlowski Cc: Arnd Bergmann, Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, anand.gore, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen On 7/13/22 15:05, Florian Fainelli wrote: > On 7/13/22 02:17, Geert Uytterhoeven wrote: >> Hi Krzysztof, >> >> On Wed, Jul 13, 2022 at 10:40 AM Krzysztof Kozlowski >> <krzysztof.kozlowski@linaro.org> wrote: >>> On 13/07/2022 10:25, Arnd Bergmann wrote: >>>> On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli >>>> <f.fainelli@gmail.com> wrote: >>>>> There are now multiple Broadcom SoCs supported so group them under >>>>> their >>>>> own menu such that the selection is visually more appealing and we can >>>>> easily add new platforms there in the future. This allows us to move >>>>> ARCH_BRCMSTB back to its siblings. >>>>> >>>>> No functional changes introduced. >>>>> >>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> >>>>> --- >>>>> >>>>> Note this is based on "arm64: bcmbca: add arch bcmbca machine entry" >>>> >>>> Hi Florian, >>>> >>>> So far, we have tried to keep the Kconfig.platforms file rather >>>> coarse-grained, >>>> mainly limiting it to company names and high-level families, but >>>> avoiding >>>> sub-menus or adding too many sub-families. >>>> >>>> If we add per-vendor submenus, we should probably first decide how we >>>> want to structure this across vendors. I've added maintainers and >>>> lists to >>>> Cc for a couple of the ones that are in a similar situation. >>>> >>>> I can see a couple of ways we can do this: >>>> >>>> a) keep the list of platforms as short as possible, combining related >>>> SoC families from a single vendor wherever possible, but no >>>> sub-menus >>>> (same as today) >>>> >>>> b) Always use sub-menus when there is more than one family, but >>>> keep relatively coarse platform selection. >>>> >>>> c) Use sub-menus and also move to a more fine-grained SoC >>>> selection, similar to what we have on 32-bit arm. >>>> >>>> I would not really want to go to c), but a) and b) both make sense to >>>> me as long as do it consistently across all platforms. >>>> >>>> Any other ideas or opinions? >>> >>> Whatever we decide here, the SoC can override in drivers/soc, just like >>> Renesas did. I think Renesas chose option c), but made it in >>> drivers/soc. I would vote to have consistent policy, so if arch/arm64 is >>> a) or b), sub-archs should not redefine it in drivers/soc. >> >> We did so because of the "only a single symbol in >> arch/arm64/Kconfig.platforms"-policy. > > I was not aware of that rule. > > It is a bit of a mixed situation with Broadcom SoCs but in essence, each > Kconfig entry denotes a deeply different SoC architecture at the memory > subsystem, bus, security or product space that you might not want to > enable in your kernel. There is definitively sharing of drivers between > all of the platforms and a lot of cross pollination too but usually > these are deeply different that different kernel images do make sense. > > The itch that I wanted to calm was that ARCH_BRCMSTB was after the other > Broadcom platforms separated by ARCH_BERLIN. if you prefer a pair of > KConfig comments to delineate them and flatten the platform selection, > that works for me, too. There are 2 Marvell-based platforms (Berlin and mvebu) as well as two NXP-based platforms (MXC and S32), would it be better to also group them under an ARCH_MARVELL and ARCH_NXP menuconfig symbol the same way this patch does it for Broadcom-based SoCs? -- Florian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-08-15 17:15 ` Florian Fainelli @ 2022-08-15 19:52 ` Arnd Bergmann 0 siblings, 0 replies; 9+ messages in thread From: Arnd Bergmann @ 2022-08-15 19:52 UTC (permalink / raw) To: Florian Fainelli Cc: Geert Uytterhoeven, Krzysztof Kozlowski, Arnd Bergmann, Linux ARM, SoC Team, bcm-kernel-feedback-list, william.zhang, anand.gore, Olof Johansson, Catalin Marinas, Will Deacon, open list, Shawn Guo, Li Yang, Wei Xu, Andrew Lunn, Gregory Clement, moderated list:ARM/Mediatek SoC..., Microchip Linux Driver Support, Matthias Brugger, linux-arm-msm, Geert Uytterhoeven, moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Dinh Nguyen On Mon, Aug 15, 2022 at 7:15 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > On 7/13/22 15:05, Florian Fainelli wrote: > > On 7/13/22 02:17, Geert Uytterhoeven wrote: > > > > The itch that I wanted to calm was that ARCH_BRCMSTB was after the other > > Broadcom platforms separated by ARCH_BERLIN. if you prefer a pair of > > KConfig comments to delineate them and flatten the platform selection, > > that works for me, too. > > There are 2 Marvell-based platforms (Berlin and mvebu) as well as two > NXP-based platforms (MXC and S32), would it be better to also group them > under an ARCH_MARVELL and ARCH_NXP menuconfig symbol the same way this > patch does it for Broadcom-based SoCs? Berlin is now Synaptics after Marvell sold them the business unit, so that one should probably stay separate. For NXP, there is also Layerscape. I agree it would be nice to group the three NXP together. Arnd ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-07-12 16:42 [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu Florian Fainelli 2022-07-13 8:25 ` Arnd Bergmann @ 2022-09-08 11:04 ` Naresh Kamboju 2022-09-08 16:43 ` Florian Fainelli 1 sibling, 1 reply; 9+ messages in thread From: Naresh Kamboju @ 2022-09-08 11:04 UTC (permalink / raw) To: f.fainelli Cc: anand.gore, arnd, bcm-kernel-feedback-list, catalin.marinas, krzysztof.kozlowski, linux-arm-kernel, linux-kernel, olof, soc, will, william.zhang, anders.roxell, lkft From: lkft@linaro.org LKFT test farm found that Linux next-20220906 onwards the Broadcom DTB builds are not happening. And after bisecting we found this patch is the reason [1]. Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> FYI, We have not changed any kernel configs. [1] http://ix.io/49Wq -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: arm64: Kconfig.platforms: Re-organized Broadcom menu 2022-09-08 11:04 ` Naresh Kamboju @ 2022-09-08 16:43 ` Florian Fainelli 0 siblings, 0 replies; 9+ messages in thread From: Florian Fainelli @ 2022-09-08 16:43 UTC (permalink / raw) To: Naresh Kamboju Cc: anand.gore, arnd, bcm-kernel-feedback-list, catalin.marinas, krzysztof.kozlowski, linux-arm-kernel, linux-kernel, olof, soc, will, william.zhang, anders.roxell, lkft On 9/8/2022 4:04 AM, Naresh Kamboju wrote: > From: lkft@linaro.org > > LKFT test farm found that Linux next-20220906 onwards the Broadcom DTB > builds are not happening. And after bisecting we found this patch is > the reason [1]. > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> > > FYI, We have not changed any kernel configs. > [1] http://ix.io/49Wq Fixed with: https://lore.kernel.org/all/20220906033957.4377-1-f.fainelli@gmail.com/ sorry about the breakage and thanks for reporting! -- Florian ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-09-08 16:43 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-12 16:42 [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu Florian Fainelli 2022-07-13 8:25 ` Arnd Bergmann 2022-07-13 8:40 ` Krzysztof Kozlowski 2022-07-13 9:17 ` Geert Uytterhoeven 2022-07-13 22:05 ` Florian Fainelli 2022-08-15 17:15 ` Florian Fainelli 2022-08-15 19:52 ` Arnd Bergmann 2022-09-08 11:04 ` Naresh Kamboju 2022-09-08 16:43 ` Florian Fainelli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).