On Mon, Apr 27, 2026 at 2:56 PM Konrad Dybcio <[email protected]> wrote: > > On 4/27/26 2:43 PM, Loic Poulain wrote: > > Add the uapi header camss-config.h defining the ISP parameter > > structures used by the CAMSS Offline Processing Engine (OPE) driver. > > This includes structures for white balance, chroma enhancement and > > color correction configuration. > > > > Signed-off-by: Loic Poulain <[email protected]> > > --- > > [...] > > > > +/** > > + * struct camss_params_wb_gain - White Balance gains > > + * > > + * @header: generic block header; @header.type = CAMSS_PARAMS_WB_GAIN > > + * @g_gain: green channel gain (15uQ10) > > + * @b_gain: blue channel gain (15uQ10) > > + * @r_gain: red channel gain (15uQ10) > > + */ > > +struct camss_params_wb_gain { > > + struct v4l2_isp_params_block_header header; > > + __u16 g_gain; > > + __u16 b_gain; > > + __u16 r_gain; > > + __u16 _pad; > > +} __attribute__((aligned(8))); > > Should this be __le for all of the related types?
At the moment, this is purely a UAPI, the values are not dumped directly to hardware as-is. Instead, each field is translated into one or more register writes, with the appropriate math, masking and shifting applied. Adding explicit endianness in the definition would therefore require special handling on both user and kernel side (to_le16, from_le16). On the other side, there are scenarios, such as platforms that rely on ICP (firmware-driven processing), where we may want to forward these structures directly within an HFI packet to the ICP MCU. In that context, explicitly defining the endianness could make some sense... Regards, Loic
