On Thu, Jan 08, 2026 at 11:49:54AM -0600, Bjorn Andersson wrote: > On Thu, Jan 08, 2026 at 04:45:49PM +0200, Dmitry Baryshkov wrote: > > On Thu, Jan 08, 2026 at 03:21:51PM +0100, Konrad Dybcio wrote: > > > From: Konrad Dybcio <[email protected]> > > > > > > To make sure the correct settings for a given DRAM configuration get > > > applied, attempt to retrieve that data from SMEM (which happens to be > > > what the BSP kernel does, albeit with through convoluted means of the > > > bootloader altering the DT with this data). > > > > > > Signed-off-by: Konrad Dybcio <[email protected]> > > > > > > --- > > > I'm not sure about this approach - perhaps a global variable storing > > > the selected config, which would then be non-const would be better? > > > > I'd prefer if const data was const, split HBB to a separate API. > > > > I agree, but I'd prefer to avoid a separate API for it. > > Instead I'd like to either return the struct by value (after updating > the hbb), but we then loose the ability to return errors, or by changing > the signature to: > > int qcom_ubwc_config_get_data(struct qcom_ubwc_cfg_data *data) > > This costs us an additional 16 bytes in each client (as the pointer is > replaced with the data), but I think it's a cleaner API.
What about: const struct qcom_ubwc_cfg_data qcom_ubwc_config_get_data(u32 *hbb) I really want to keep the data as const and, as important, use it as a const pointer. > > Regards, > Bjorn -- With best wishes Dmitry
