Re: [PATCH v6 5/8] media: qcom: camss: csiphy-3ph: Add Gen2 v1.1 MIPI CSI-2 C-PHY init

[Michael Srba]

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