Re: [PATCH] clk: mmp: allow COMPILE_TEST builds
Rosen Penev <[email protected]> Mon, 20 Jul 2026 18:04:03 -0700
| Newsgroups | dev.linux.lists.llvm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-clk,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAKxU2N9VoHRUGGjEsMCEyGaMxoc=Bw0tuuMb-BYn+54DJRjQWA@mail.gmail.com> |
On Mon, Jul 20, 2026 at 1:08 PM Brian Masney <[email protected]> wrote: > > Hi Duje, > > On Mon, Jul 20, 2026 at 04:46:40PM +0200, Duje Mihanović wrote: > > On Sunday, 19 July 2026 23:43:49 Central European Summer Time Rosen Penev > > wrote: > > > > [...] > > > > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > > > index 4b2c089f46a1..8383f9f1da51 100644 > > > --- a/drivers/clk/Makefile > > > +++ b/drivers/clk/Makefile > > > @@ -130,7 +130,7 @@ obj-y += > > mediatek/ > > > obj-$(CONFIG_ARCH_MESON) += meson/ > > > obj-y += microchip/ > > > ifeq ($(CONFIG_COMMON_CLK), y) > > > -obj-$(CONFIG_ARCH_MMP) += mmp/ > > > +obj-$(CONFIG_COMMON_CLK_MMP) += mmp/ > > > > Could it be possible to select mmp unconditionally, like most of the other > > subtrees are? AFAICT, that would also require creating new Kconfig symbols for > > the PXA168, PXA910 and PXA1928 clocks, but I suspect it may be the more proper > > choice in the long term. > > Just by sheer numbers, the CONFIG_COMMON_CLK_XXX approach is the most > common use case right now. It's much simpler this way. > > x1:~/src/linux/linux-next ((next-20260720) %)$ grep "CONFIG_COMMON_CLK" drivers/clk/Makefile | grep "+=" | wc -l > 68 > x1:~/src/linux/linux-next ((next-20260720) %)$ grep "obj-y" drivers/clk/Makefile | wc -l > 25 > > I have no strong opinions about this either way other than to drive > consistency across various drivers as much as possible. > > Currently the mmp directory currently only has COMMON_CLK_PXA1908 > defined. When the other PXA* drivers are introduced, will there be a > CONFIG_COMMON_CLK_MMA_COMMON that all of the drivers will use? > > If so, we could put that MMA_COMMON in the toplevel clk Makefile. > > If not, then yes I agree that obj-y will be fine. > > Brian >