From: Baoquan He <bhe@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, mingo@kernel.org
Cc: linux-kernel@vger.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: Wed, 20 Nov 2024 15:56:24 +0800 [thread overview]
Message-ID: <Zz2WKFxkOJNZrI5H@MiWiFi-R3L-srv> (raw)
In-Reply-To: <ZzwA53x3KYQgDbeQ@MiWiFi-R3L-srv>
On 11/19/24 at 11:07am, Baoquan He wrote:
> On 11/18/24 at 09:19am, Tom Lendacky wrote:
> > On 11/17/24 19:08, Baoquan He wrote:
......snip.......
> > > /*
> > > * 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,
Hi Tom, Ingo,
What's your suggestion about the __init and __ref adding/removing on
below functions as Tom pointed out?
> >
> > 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-20 7:56 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
2024-11-19 10:55 ` Ingo Molnar
2024-11-20 7:21 ` Baoquan He
2024-11-20 7:56 ` Baoquan He [this message]
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=Zz2WKFxkOJNZrI5H@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.