Re: [PATCH v4 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver

[Bryan O'Donoghue <bod@kernel.org>]

On 11/06/2026 09:51, Konrad Dybcio wrote:
>>> implementation simpler, avoids unnecessary abstraction, and makes debugging—through direct
>>> comparison with the hardware spec easier.
>> How are hex values in upstream code easier to debug ?
>>
>> Without the spec you can't change or understand hex values in upstream code, which is the whole point I'm making here.
> I get the 'understanding' part, but regarding change, as I said
> previously, these must remain as-is - any difference for a PLL
> impacts every single clock downstream of it. Some of them also
> correspond to specific electrical properties, just like with PHY
> init sequences. The existing values are a result of tuning and
> silicon validation across presumably many, many chip units.

That's an argument against changing the values, not naming the values. 
Hexwork in upstream code is a public black box and should be avoided 
where possible.

How about, take these fixed hex but someone on the clock-side in qcom 
agrees to update the script to write defined bitfields not hexwork in 
future deliveries. AFAIU its a script that mostly spits out these clock 
descriptors so, it should be possible to fix that script once @ source, 
without committing to fixing everything _currently_ in flight.

Qcom can then at its leisure update old controller descriptors by 
running the script again.

> There may be updates (very rarely post the chip going into
> production), but I'd assume these would go through the same
> testing procedures
> 
> Konrad


---
bod