hi Simon,
On Mon, 15 Jul 2024 at 17:09, Simon Glass <s...@chromium.org> wrote:
>
> 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.
Okay, I will bring in that patch earlier in the series.
-sughosh
> [..]
>
> Regards,
> Simon
