[PATCH] clk: ti: Tighten some TI clock driver dependencies

Chawdhry, Manorit m-chawdhry at ti.com
Mon Oct 6 08:11:31 CEST 2025


Hi Tom,

On 10/1/2025 9:05 PM, Tom Rini wrote:
> On Wed, Oct 01, 2025 at 05:08:46PM +0530, Chawdhry, Manorit wrote:
>> Hi Tom,
>>
>> On 9/26/2025 9:01 PM, Tom Rini wrote:
>>> A few of the TI clock drivers cannot link without access to TI platform
>>> specific drivers and headers.  Express those requirements in Kconfig as
>>> well.
>>>
>>> Signed-off-by: Tom Rini <trini at konsulko.com>
>>> ---
>>> Cc: Lukasz Majewski <lukma at denx.de>
>>> Cc: Sean Anderson <seanga2 at gmail.com>
>>> Cc: Manorit Chawdhry <m-chawdhry at ti.com>
>>> Cc: Andrew Davis <afd at ti.com>
>>> Cc: Udit Kumar <u-kumar1 at ti.com>
>>> ---
>>>    drivers/clk/ti/Kconfig | 6 +++---
>>>    1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
>>> index e0f15f57f826..ba658c741c4d 100644
>>> --- a/drivers/clk/ti/Kconfig
>>> +++ b/drivers/clk/ti/Kconfig
>>> @@ -18,19 +18,19 @@ config CLK_TI_CTRL
>>>    config CLK_TI_DIVIDER
>>>    	bool "TI divider clock driver"
>>> -	depends on CLK && OF_CONTROL && CLK_CCF
>>> +	depends on CLK && OF_CONTROL && CLK_CCF && ARCH_OMAP2PLUS
>>>    	help
>>>    	  This enables the divider clock driver support on TI's SoCs.
>>>    config CLK_TI_GATE
>>>    	bool "TI gate clock driver"
>>> -	depends on CLK && OF_CONTROL
>>> +	depends on CLK && OF_CONTROL && ARCH_OMAP2PLUS
>>>    	help
>>>    	  This enables the gate clock driver support on TI's SoCs.
>>>    config CLK_TI_MUX
>>>    	bool "TI mux clock driver"
>>> -	depends on CLK && OF_CONTROL && CLK_CCF
>>> +	depends on CLK && OF_CONTROL && CLK_CCF && ARCH_OMAP2PLUS
>>>    	help
>>>    	  This enables the mux clock driver support on TI's SoCs.
>>
>> Do other Kconfigs' work in this file without access to TI platform specific
>> drivers and headers? am wondering that every Kconfig in this file would
>> ideally be TI specific only..
> 
> Ideally, long term we could build all of this on sandbox with
> allyesconfig and get static analysis done to it easily. But also yes,
> after this second patch here every driver has a ARCH dependency because
> the ones that wouldn't compile without a header caused others to fail to
> link. This also tells me that some of these options should be select'd
> by others, rather than everything being a question.
> 

Ah okay, understood. Though I was just trying to understand who were the 
ones trying to use it, as I just see these configs being used in 
`am335x_guardian_defconfig` only. I would assume that until someone 
enables it explicitly ( and can't think of why would they if these are 
TI specific and also in TI specific folders )

Though given that you mentioned sandbox testing, I think we should 
capture the motivation in the commit message too for this ( as otherwise 
at least for me it feels confusing as to why would someone end up and 
start using a TI specific driver when it's in TI specific folder as well )

Though just to experiment, I tried a quick build test with adding these 
configs on j7200 R5 defconfig and can see it fail for them even. So this 
patch looks very specific to ARCH_OMAP2PLUS itself so might be good to 
capture that in the commit message too IMO [ as even TI related 
platforms fail to link ]

I think would suggest commit message improvements only, with that -

Reviewed-by: Manorit Chawdhry <m-chawdhry at ti.com>

Regards,
Manorit







More information about the U-Boot mailing list