Hi,
On 6/5/26 12:25, Bryan O'Donoghue wrote:
On 03/06/2026 22:53, Frank Li wrote:
+ {CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(25), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(55), 0x51, 0x00, CSIPHY_DEFAULT_PARAMS},
what's these magic number in ADDR(x), if it is register, it'd better to use
macro.
That's not really feasible for non-Qualcomm, non-vendor document-enabled people
to provide. For alot of the code that gets sent to upstream we have
magic-numbers for registers only, published in downstream code.
We can't demand better documentation from community members who simply don't
have it.
Makes sense.
So, hex values from downstream in this case are acceptable.
OTOH vendors can and should enumerate their registers in an upstream submission.
I thought this was the policy indeed, but this made me wonder if ALL the magic
numbers
in that file were added by volunteers. And weirdly I found this:
https://github.com/torvalds/linux/commit/7803b63a1640a0a39e3ebad487b33cb2d26e778b
and possibly some other commits look like they were made by people on Qualcomm's
payroll. This specifically is QUIC, and idk how much documentation access they
have,
but at minimum I assume they had access to the CTRLn register names? (fwiw it's
entirely
plausible that the registers don't actually *have* better names).
I didn't follow the relevant ML discussions, but it seems to me like they
should've
been told to document the registers?
And even if the documentation they have is not complete, seeing as they are
being paid
by Qualcomm to work on this, would it be unreasonable to pressure Qualcomm to
give them
documentation for the bitfields (which obviously has to exist *somewhere*, even
if
the registers are free-form, the values do *something*).
- Michael
---
bod
