Expose for_each_present_section_nr() to be used by drivers/base/memory
in the next patch.

No functional changes intended.

Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 include/linux/mmzone.h | 5 +++++
 mm/sparse.c            | 5 -----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9540b41894da..0f6646da34d7 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -2097,6 +2097,11 @@ static inline unsigned long next_present_section_nr(unsigned long section_nr)
 	return -1;
 }
 
+#define for_each_present_section_nr(start, section_nr)		\
+	for (section_nr = next_present_section_nr(start - 1);	\
+	     section_nr != -1;					\
+	     section_nr = next_present_section_nr(section_nr))
+
 /*
  * These are _only_ used during initialisation, therefore they
  * can use __initdata ...  They could have names to indicate
diff --git a/mm/sparse.c b/mm/sparse.c
index 133b033d0cba..fe77d523ab8d 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -170,11 +170,6 @@ static void __section_mark_present(struct mem_section *ms,
 	ms->section_mem_map |= SECTION_MARKED_PRESENT;
 }
 
-#define for_each_present_section_nr(start, section_nr)		\
-	for (section_nr = next_present_section_nr(start-1);	\
-	     section_nr != -1;								\
-	     section_nr = next_present_section_nr(section_nr))
-
 static inline unsigned long first_present_section_nr(void)
 {
 	return next_present_section_nr(-1);
-- 
2.48.1

On 11.03.25 01:46, Gavin Shan wrote:
> Expose for_each_present_section_nr() to be used by drivers/base/memory
> in the next patch.
> 
> No functional changes intended.
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>

Please squash that into the patch that uses it.

-- 
Cheers,

David / dhildenb

On 3/11/25 7:31 PM, David Hildenbrand wrote:
> On 11.03.25 01:46, Gavin Shan wrote:
>> Expose for_each_present_section_nr() to be used by drivers/base/memory
>> in the next patch.
>>
>> No functional changes intended.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
> 
> Please squash that into the patch that uses it.
> 

Yes, but this series has been queued by Andrew Morton. Andrew, would
you mind to squash PATCH[3/1] to PATCH[2/3]? Or I can respin to do that
in v3.

Thanks,
Gavin

On Tue, Mar 11, 2025 at 09:52:09PM +1000, Gavin Shan wrote:
> Yes, but this series has been queued by Andrew Morton. Andrew, would
> you mind to squash PATCH[3/1] to PATCH[2/3]? Or I can respin to do that
> in v3.

Since it is in mm-unstable, maybe just resend a v3 with all acks + this
squashed and be done with it.


-- 
Oscar Salvador
SUSE Labs

On 3/12/25 1:26 AM, Oscar Salvador wrote:
> On Tue, Mar 11, 2025 at 09:52:09PM +1000, Gavin Shan wrote:
>> Yes, but this series has been queued by Andrew Morton. Andrew, would
>> you mind to squash PATCH[3/1] to PATCH[2/3]? Or I can respin to do that
>> in v3.
> 
> Since it is in mm-unstable, maybe just resend a v3 with all acks + this
> squashed and be done with it.
> 

Thanks for suggestions. v3 has been sent with the changes.

https://lore.kernel.org/linux-mm/20250311233045.148943-1-gshan@redhat.com/T/#t

Thanks,
Gavin