Hi Sughosh,
On Mon, 15 Jul 2024 at 10:27, Sughosh Ganu <sughosh.g...@linaro.org> wrote:
>
> hi Simon,
>
> On Sat, 13 Jul 2024 at 20:45, Simon Glass <s...@chromium.org> wrote:
> >
> > Hi Sughosh,
> >
> > On Thu, 4 Jul 2024 at 08:36, Sughosh Ganu <sughosh.g...@linaro.org> wrote:
> > >
> > > Allow for resizing of LMB regions if the region attributes match. The
> > > current code returns a failure status on detecting an overlapping
> > > address. This worked up until now since the LMB calls were not
> > > persistent and global -- the LMB memory map was specific and private
> > > to a given caller of the LMB API's.
> > >
> > > With the change in the LMB code to make the LMB reservations
> > > persistent, there needs to be a check on whether the memory region can
> > > be resized, and then do it if so. To distinguish between memory that
> > > cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a region
> > > of memory with this attribute would indicate that the region cannot be
> > > resized.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org>
> > > ---
> > > Changes since V1:
> > > * Do the check for the region flags in lmb_resize_regions() and
> > > lmb_merge_overlap_regions() to decide on merging the overlapping
> > > regions.
> > >
> > > include/lmb.h | 1 +
> > > lib/lmb.c | 116 ++++++++++++++++++++++++++++++++++++++++++++------
> > > 2 files changed, 103 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/include/lmb.h b/include/lmb.h
> > > index 069c6af2a3..99fcf5781f 100644
> > > --- a/include/lmb.h
> > > +++ b/include/lmb.h
> > > @@ -20,6 +20,7 @@
> > > enum lmb_flags {
> > > LMB_NONE = 0x0,
> > > LMB_NOMAP = 0x4,
> > > + LMB_NOOVERWRITE = 0x8,
> >
> > How about LMB_PERSIST ?
>
> Isn't LMB_NOOVERWRITE more suitable here ? I mean this is indicating
> that the said region of memory is not to be re-used/re-requested.
>
> >
> > These could be adjusted to use BIT()
>
> I am changing these to use the BIT macro in a subsequent commit.
Yes, I saw that later and forgot to remove this. Normally we make
refactoring changes before adding new code, though.
[..]
Regards,
Simon
