From: Baoquan He <bhe@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, bp@alien8.de,
x86@kernel.org
Subject: Re: [PATCH v2 1/2] x86/ioremap: introduce helper to implement xxx_is_setup_data()
Date: Tue, 19 Nov 2024 11:07:19 +0800 [thread overview]
Message-ID: <ZzwA53x3KYQgDbeQ@MiWiFi-R3L-srv> (raw)
In-Reply-To: <7cc5e26c-42fc-a700-ae19-608920cafe44@amd.com>
On 11/18/24 at 09:19am, Tom Lendacky wrote:
> On 11/17/24 19:08, Baoquan He wrote:
> > Functions memremap_is_setup_data() and early_memremap_is_setup_data()
> > share completely the same process and handling, except of the
> > different memremap/unmap invocations.
> >
> > So add helper __memremap_is_setup_data() to extract the common part,
> > parameter 'early' is used to decide what kind of memremap/unmap
> > APIs are called. This simplifies codes a lot by removing the duplicated
> > codes, and also removes the similar code comment above them.
> >
> > And '__ref' is added to __memremap_is_setup_data() to suppress below
> > section mismatch warning:
> >
> > ARNING: modpost: vmlinux: section mismatch in reference: __memremap_is_setup_data+0x5f (section: .text) ->
> > early_memunmap (section: .init.text)
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > arch/x86/mm/ioremap.c | 108 +++++++++++++++---------------------------
> > 1 file changed, 38 insertions(+), 70 deletions(-)
> >
> > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> > index 8d29163568a7..68d78e2b1203 100644
> > --- a/arch/x86/mm/ioremap.c
> > +++ b/arch/x86/mm/ioremap.c
> > @@ -628,12 +628,13 @@ static bool memremap_is_efi_data(resource_size_t phys_addr,
> > return false;
> > }
> >
> > +#define SD_SIZE sizeof(struct setup_data)
>
> Nit, I still think you should use "sizeof(*data)" in the code instead of
> creating a #define.
Thanks for reviewing, Tom.
Boris suggested this. Both is fine to me. If there is indeed a tiny
preference, I would choose SD_SIZE. It's going a bit far, but not too
far.
>
> > /*
> > * Examine the physical address to determine if it is boot data by checking
> > * it against the boot params setup_data chain.
> > */
> > -static bool memremap_is_setup_data(resource_size_t phys_addr,
> > - unsigned long size)
> > +static bool __ref __memremap_is_setup_data(resource_size_t phys_addr,
>
> Oh, I see why the __ref is needed now, because this calls an __init
> function based on the early bool.
Exactly, I explained in another thread replying to you, it could be
ignored.
>
> While this nicely consolidates the checking, I'll let the x86
> maintainers decide whether they like that an __init function is calling
> a non __init function.
...... snip.......
> > - return false;
> > +static bool early_memremap_is_setup_data(resource_size_t phys_addr,
>
> This should retain the original __init reference.
OK, so you suggest they are like below, right?
static bool __ref __memremap_is_setup_data(resource_size_t phys_addr,
bool early)
{
......
}
static bool memremap_is_setup_data(resource_size_t phys_addr)
{
return __memremap_is_setup_data(phys_addr, false);
}
static bool __init early_memremap_is_setup_data(resource_size_t phys_addr)
{
return __memremap_is_setup_data(phys_addr, true);
}
I can make v3 if we all agree on this.
next prev parent reply other threads:[~2024-11-19 3:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 1:08 [PATCH v2 0/2] x86/ioremap: clean up the mess in xxx_is_setup_data Baoquan He
2024-11-18 1:08 ` [PATCH v2 1/2] x86/ioremap: introduce helper to implement xxx_is_setup_data() Baoquan He
2024-11-18 15:19 ` Tom Lendacky
2024-11-19 3:07 ` Baoquan He [this message]
2024-11-19 10:55 ` Ingo Molnar
2024-11-20 7:21 ` Baoquan He
2024-11-20 7:56 ` Baoquan He
2024-11-20 8:25 ` Ingo Molnar
2024-11-20 14:14 ` Tom Lendacky
2024-11-25 9:07 ` Ingo Molnar
2024-11-26 8:15 ` Baoquan He
2024-11-18 1:08 ` [PATCH v2 2/2] x86/mm: clean up unused parameters of functions Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzwA53x3KYQgDbeQ@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.