On Wed, 21 May 2025 at 13:23, Ilias Apalodimas
<ilias.apalodi...@linaro.org> wrote:
>
> Hi Sughosh
>
> On Tue May 20, 2025 at 3:06 PM EEST, Sughosh Ganu wrote:
> > There currently are multiple allocation API's in the LMB module. There
> > are a couple of API's for allocating memory(lmb_alloc() and
> > lmb_alloc_base()), and then there are two for requesting a reservation
> > for a particular memory region (lmb_reserve() and
> > lmb_alloc_addr()). Introduce a single API lmb_allocate_mem() which
> > will cater to all types of allocation requests and replace
> > lmb_reserve() and lmb_alloc_addr() with the new API.
> >
> > Moreover, the lmb_reserve() API is pretty similar to the
> > lmb_alloc_addr() API, with the one difference being that the
> > lmb_reserve() API allows for reserving any address passed to it --
> > the address need not be part of the LMB memory map. The
> > lmb_alloc_addr() does check that the address being requested is
> > actually part of the LMB memory map.
> >
> > There is no need to support reserving memory regions which are outside
> > the LMB memory map. Remove the lmb_reserve() API functionality and use
> > the functionality provided by lmb_alloc_addr() instead. The
> > lmb_alloc_addr() will check if the requested address is part of the
> > LMB memory map and return an error if not.
> >
> >        * there's no need to check the result
> >        */
> >       arm_smccc_smc(MTK_SIP_GET_BL31_REGION, 0, 0, 0, 0, 0, 0, 0, &res);
> > -     lmb_reserve(res.a1, res.a2, LMB_NOMAP);
> > +     addr = (phys_addr_t)res.a1;
> > +     lmb_allocate_mem(LMB_MEM_ALLOC_ADDR, 0, &addr, res.a2, LMB_NOMAP);
>
> In some case you check the return value and in others you ignore it.
> Since you are changing this, check the return address everywhere

Yes, I mentioned this in the cover-letter. I have kept the code in
arch-specific functions as is when it comes to error checking, as I do
not have the associated boards with me. I am not sure what side
effects erroring out would have. It would be better if the respective
custodians/maintainers fix this, as it would ensure no breakage.


>
> > + * be -EINVAL if the requested memory region is not part of the LMB memory
> > + * map, and -EEXIST if the requested region is already allocated.
> > + */
> > +int lmb_allocate_mem(enum lmb_mem_type type, u64 align, phys_addr_t *addr,
>
> Nit, but can you rename it to lmb_alloc_mem() so it uses abbreviations 
> everywhere?

You mean a shorter name? I had pondered over using lmb_alloc_mem()
instead earlier, but thought about using the current one, as this is a
globally visible API.

>
> > +/**
> > + * lmb_can_reserve_region() - check if the region can be reserved
> > + * @base: base address of region to be reserved
> > + * @size: size of region to be reserved
> > + * @flags: flag of the region to be reserved
> > + *
> > + * Go through all the reserved regions and ensure that the requested
> > + * region does not overlap with any existing regions. An overlap is
> > + * allowed only when the flag of the request region and the existing
> > + * region is LMB_NONE.
> > + *
> > + * Return: true if region can be reserved, false otherwise
> > + */
> > +static bool lmb_can_reserve_region(phys_addr_t base, phys_size_t size,
> > +                                u32 flags)
>
> Overall this is a good cleanup. But I was hoping we can rid of this as well.
> This is almost identical to lmb_overlaps_region() with very small differences.
> One of these takes the lmb list as an argument and the other is also checking 
> some flags.
> It's better if we keep one.

I can get rid of the above function. It would require putting the
checks for the flags in the calling function, but we can indeed use
lmb_overlaps_region() instead. I will put this in a separate patch.
Thanks.

>
> [...]
>
> Overall this is moving towards thr gith direction

Good to know :)

-sughosh

>
> Cheers
> /Ilias

Reply via email to