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

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

On 25/05/2026 08:06, Jagadeesh Kona wrote:
>> That's not in your overview letter so generally I'd advise to include things like "did X because Y" - "didn't do Q because Z" anyway, how does it make a difference if the values are static ?
>>
>> They are no less magic numbers that way.
>>
>> What exactly is the resistance to defining the bits ?
>>
>> I'll state again - when a vendor is submitting something upstream where that vendor 100% controls their own documentation - there's no reason at all to be presenting magic hex numbers - even more the case with generated code.
>>
>> Just update the script to enumerate the bit fields, I honestly don't get the aversion.
>>
> Hi Bryan,
> 
> There’s no standard interface for these bits, and bit definitions/fields vary across PLL types.
> So, common macros aren’t feasible and would need redefinitions per controller. Since these bits
> are not reused elsewhere

- Asking for named bits not common macros
- Reuse isn't why you name a bit

, IMO directly using values from the hardware documentation keeps the
> 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.

---
bod