All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: WangYuli <wangyuli@uniontech.com>
Cc: dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	linux-kernel@vger.kernel.org, zhanjun@uniontech.com,
	niecheng1@uniontech.com, chenlinxuan@uniontech.com,
	Huacai Chen <chenhuacai@loongson.cn>,
	Wentao Guan <guanwentao@uniontech.com>
Subject: Re: [PATCH] x86/srat: Conditional apic_id vs MAX_LOCAL_APIC comparison
Date: Fri, 28 Feb 2025 10:32:59 +0100	[thread overview]
Message-ID: <Z8GCyyt0Dud0kvwq@gmail.com> (raw)
In-Reply-To: <E053FB6951F019A2+20250228051847.50002-1-wangyuli@uniontech.com>


* WangYuli <wangyuli@uniontech.com> wrote:

> The apic_id employed within the acpi_numa_processor_affinity_init()
> function is derived from the acpi_srat_cpu_affinity structure defined
> in acpi/actbl3.h.
> 
> When CONFIG_X86_X2APIC is not enabled, its maximum value is limited
> to 255.

How does the compiler know the value is limited to 0-255?

<acpi/actbl3.h> has an u32 apic_id field:

 struct acpi_srat_x2apic_cpu_affinity {
        struct acpi_subtable_header header;
        u16 reserved;           /* Reserved, must be zero */
        u32 proximity_domain;
        u32 apic_id;
        ^^^^^^^^^^^^
        u32 flags;
        u32 clock_domain;
        u32 reserved2;
 };

and the apic_id local variable in acpi_numa_processor_affinity_init() 
is an 'int':

        int apic_id;

Neither is limited to 0-255.

Thanks,

	Ingo

  reply	other threads:[~2025-02-28  9:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28  5:18 [PATCH] x86/srat: Conditional apic_id vs MAX_LOCAL_APIC comparison WangYuli
2025-02-28  9:32 ` Ingo Molnar [this message]
2025-03-03  3:42   ` WangYuli

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=Z8GCyyt0Dud0kvwq@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=chenhuacai@loongson.cn \
    --cc=chenlinxuan@uniontech.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=guanwentao@uniontech.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=niecheng1@uniontech.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=wangyuli@uniontech.com \
    --cc=x86@kernel.org \
    --cc=zhanjun@uniontech.com \
    /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.