[PATCH v3 02/15] lmb: add a flag to allow suppressing memory map change notification

[Tom Rini]

On Mon, Oct 14, 2024 at 12:26:02PM +0530, Sughosh Ganu wrote:
> On Sun, 13 Oct 2024 at 23:21, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sun, Oct 13, 2024 at 04:25:09PM +0530, Sughosh Ganu wrote:
> >
> > > Add a flag LMB_NONOTIFY that can be passed to the LMB API's for
> > > reserving memory. This will then result in no notification being sent
> > > from the LMB module for the changes to the LMB's memory map.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> >
> > Can you please elaborate on what we need this flag for, for example what
> > the valid situation for it is? We should be updating (or adding comments
> > such that updates are automatic..) to doc/api/lmb.rst as well. Thanks.
> 
> The flag is used to prevent notifying the EFI code about the change in
> the LMB memory map when the alloc/free request originates in the EFI
> memory module.

Simon, this is the loop you referred to on IRC the other day, and
instead you solve this with the flag about a point of cooperation?

> The EFI memory module adds the memory region to its
> memory map as part of the alloc/free operation. The idea is that the
> LMB module should notify EFI about changes to its memory map when
> these changes are initiated from non-EFI consumers of memory.

OK, so the first change is that since doc/api/lmb.rst is just a
kerneldoc of include/lmb.h we need to add the flag here, and we need to
first document LMB_NOOVERWRITE which is already undocumented. The next
change is that at the end of the series, update the rst with some
paragraphs about what and why, for clarity, after auditing include/lmb.h
for other items that are missing kerneldoc comments. I am willing to
make that second change a follow-up series, however.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241014/8daa5018/attachment.sig>