Koralahalli Channabasappa, Smita wrote:
> Hi,
>
> Sorry for the delay here. I was on vacation. Responses inline.
>
> On 12/2/2025 2:19 PM, [email protected] wrote:
> > Smita Koralahalli wrote:
> >> From: Dan Williams <[email protected]>
> >>
> >> Insert Soft Reserved memory into a dedicated soft_reserve_resource tree
> >> instead of the iomem_resource tree at boot. Delay publishing these ranges
> >> into the iomem hierarchy until ownership is resolved and the HMEM path
> >> is ready to consume them.
> >>
> >> Publishing Soft Reserved ranges into iomem too early conflicts with CXL
> >> hotplug and prevents region assembly when those ranges overlap CXL
> >> windows.
> >>
> >> Follow up patches will reinsert Soft Reserved ranges into iomem after CXL
> >> window publication is complete and HMEM is ready to claim the memory. This
> >> provides a cleaner handoff between EFI-defined memory ranges and CXL
> >> resource management without trimming or deleting resources later.
> >
> > Please, when you modify a patch from an original, add your
> > Co-developed-by: and clarify what you changed.
>
> Thanks Dan. Yeah, this was a bit of a gray area for me. I had the
> impression or remember reading somewhere that Co-developed-by tags are
> typically added only when the modifications are substantial, so I didn’t
> include it initially. I will add the Co-developed-by: line.
Yes, there are no hard and fast rules here. My expectation is that if
you make any changes to a patch that change its "git patch-id" result,
then add Co-developed-by. If you make "substantial" modifcations then
consider taking Authorship and move the original Author to
Co-developed-by.
[..]
> >> +void insert_resource_expand_to_fit(struct resource *new)
> >> +{
> >> + struct resource *root = &iomem_resource;
> >> +
> >> +#ifdef CONFIG_EFI_SOFT_RESERVE
> >> + if (new->desc == IORES_DESC_SOFT_RESERVED)
> >> + root = &soft_reserve_resource;
> >> +#endif
> >
> > I can not say I am entirely happy with this change, I would prefer to
> > avoid ifdef in C, and I would prefer not to break the legacy semantics
> > of this function, but it meets the spirit of the original RFC without
> > introducing a new insert_resource_late(). I assume review feedback
> > requested this?
>
> Yeah here,
> https://lore.kernel.org/all/20250909161210.GBaMBR2rN8h6eT9JHe@fat_crate.local/
Thanks, I will go reply there.
