From: "Rafael J. Wysocki" <rjw@rjwysocki•net>
To: Stephen Rothwell <sfr@canb•auug.org.au>,
Hanjun Guo <hanjun.guo@linaro•org>
Cc: Thomas Gleixner <tglx@linutronix•de>, Ingo Molnar <mingo@elte•hu>,
"H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
Jiang Liu <jiang.liu@linux•intel.com>,
Yinghai Lu <yinghai@kernel•org>
Subject: Re: linux-next: manual merge of the tip tree with the pm tree
Date: Tue, 25 Nov 2014 22:16:13 +0100 [thread overview]
Message-ID: <1793317.oUQRzfcXxI@vostro.rjw.lan> (raw)
In-Reply-To: <20141125164640.05d99ea5@canb.auug.org.au>
On Tuesday, November 25, 2014 04:46:40 PM Stephen Rothwell wrote:
>
> --Sig_/T.+7iMvUwEH92u+UTGF86Po
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
>
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> drivers/acpi/processor_core.c between commit 9d48ea9f967b ("ACPI /
> processor: Convert apic_id to phys_id to make it arch agnostic") from
> the pm tree and commits 5922b6f497ed ("ACPI: Fix minor syntax issues in
> processor_core.c") and 717ed6192d16 ("ACPI: Add interfaces to parse
> IOAPIC ID for IOAPIC hotplug") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Since the material in my acpi-processor branch is only a cleanup, I'm
dropping it from linux-next. We'll rebase it and apply it later when
the IOAPIC hotplug stuff settles.
Rafael
> diff --cc drivers/acpi/processor_core.c
> index 0f6f73ed41f2,f124cbb491d9..000000000000
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su
> static int map_madt_entry(int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> - static struct acpi_table_madt *madt;
> - static int read_madt;
> - int apic_id =3D -1;
> + int phys_id =3D -1; /* CPU hardware ID */
> + struct acpi_table_madt *madt;
> =20
> - if (!read_madt) {
> - if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
> - (struct acpi_table_header **)&madt)))
> - madt =3D NULL;
> - read_madt++;
> - }
> -=20
> + madt =3D get_madt_table();
> if (!madt)
> - return apic_id;
> + return phys_id;
> =20
> entry =3D (unsigned long)madt;
> madt_end =3D entry + madt->header.length;
> @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha
> }
> =20
> header =3D (struct acpi_subtable_header *)obj->buffer.pointer;
> - if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) {
> + if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC)
> - map_lapic_id(header, acpi_id, &apic_id);
> + map_lapic_id(header, acpi_id, &phys_id);
> - } else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) {
> + else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC)
> - map_lsapic_id(header, type, acpi_id, &apic_id);
> + map_lsapic_id(header, type, acpi_id, &phys_id);
> - } else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) {
> + else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC)
> - map_x2apic_id(header, type, acpi_id, &apic_id);
> + map_x2apic_id(header, type, acpi_id, &phys_id);
> - }
> =20
> exit:
> kfree(buffer.pointer);
> @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp
> =20
> int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
> {
> - int apic_id;
> + int phys_id;
> =20
> - apic_id =3D acpi_get_apicid(handle, type, acpi_id);
> + phys_id =3D acpi_get_phys_id(handle, type, acpi_id);
> =20
> - return acpi_map_cpuid(apic_id, acpi_id);
> + return acpi_map_cpuid(phys_id, acpi_id);
> }
> EXPORT_SYMBOL_GPL(acpi_get_cpuid);
> +=20
> + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
> + u64 *phys_addr, int *ioapic_id)
> + {
> + struct acpi_madt_io_apic *ioapic =3D (struct acpi_madt_io_apic *)entry;
> +=20
> + if (ioapic->global_irq_base !=3D gsi_base)
> + return 0;
> +=20
> + *phys_addr =3D ioapic->address;
> + *ioapic_id =3D ioapic->id;
> + return 1;
> + }
> +=20
> + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr)
> + {
> + struct acpi_subtable_header *hdr;
> + unsigned long madt_end, entry;
> + struct acpi_table_madt *madt;
> + int apic_id =3D -1;
> +=20
> + madt =3D get_madt_table();
> + if (!madt)
> + return apic_id;
> +=20
> + entry =3D (unsigned long)madt;
> + madt_end =3D entry + madt->header.length;
> +=20
> + /* Parse all entries looking for a match. */
> + entry +=3D sizeof(struct acpi_table_madt);
> + while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
> + hdr =3D (struct acpi_subtable_header *)entry;
> + if (hdr->type =3D=3D ACPI_MADT_TYPE_IO_APIC &&
> + get_ioapic_id(hdr, gsi_base, phys_addr, &apic_id))
> + break;
> + else
> + entry +=3D hdr->length;
> + }
> +=20
> + return apic_id;
> + }
> +=20
> + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
> + u64 *phys_addr)
> + {
> + struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_subtable_header *header;
> + union acpi_object *obj;
> + int apic_id =3D -1;
> +=20
> + if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
> + goto exit;
> +=20
> + if (!buffer.length || !buffer.pointer)
> + goto exit;
> +=20
> + obj =3D buffer.pointer;
> + if (obj->type !=3D ACPI_TYPE_BUFFER ||
> + obj->buffer.length < sizeof(struct acpi_subtable_header))
> + goto exit;
> +=20
> + header =3D (struct acpi_subtable_header *)obj->buffer.pointer;
> + if (header->type =3D=3D ACPI_MADT_TYPE_IO_APIC)
> + get_ioapic_id(header, gsi_base, phys_addr, &apic_id);
> +=20
> + exit:
> + kfree(buffer.pointer);
> + return apic_id;
> + }
> +=20
> + /**
> + * acpi_get_ioapic_id - Get IOAPIC ID and physical address matching @gsi_=
> base
> + * @handle: ACPI object for IOAPIC device
> + * @gsi_base: GSI base to match with
> + * @phys_addr: Pointer to store physical address of matching IOAPIC record
> + *
> + * Walk resources returned by ACPI_MAT method, then ACPI MADT table, to s=
> earch
> + * for an ACPI IOAPIC record matching @gsi_base.
> + * Return IOAPIC id and store physical address in @phys_addr if found a m=
> atch,
> + * otherwise return <0.
> + */
> + int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
> + {
> + int apic_id;
> +=20
> + apic_id =3D parse_mat_ioapic_entry(handle, gsi_base, phys_addr);
> + if (apic_id =3D=3D -1)
> + apic_id =3D parse_madt_ioapic_entry(gsi_base, phys_addr);
> +=20
> + return apic_id;
> + }
> + #endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */
>
> --Sig_/T.+7iMvUwEH92u+UTGF86Po
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJUdBfGAAoJEMDTa8Ir7ZwVeAMP/jT/rc43RxXIRBIBOb9oWDuE
> NTEMECD6ziGKOS2fqz+BqdAEDLi+wdYn3ba52U8SHTXBFN63lQc5ISQ+EUpeR7Pb
> jp5i9BiiL2RPPNSjQNZ8x1EZSnnGkIo9DwfH3uq75SwTDT+a8kMH618QGb0oDasY
> duafSmDbvVSxPZevxWtCsdLjU52ssB64PKUiugCBJyhup4JQW8wWdZ30w7AkUbUQ
> sBFtR01BXtLZ/wNX971821APvs/c/rZHE6a6cZoasN98E4p38k0pGcLrcUGiqdIO
> ORckMzsQghFj1gAMxzyHRg1c09ORuE19AZlAHF4W2nKJ18tW66/QG8+HCk+Z3R8z
> zkfOm5QFuQbYLoMyhyZ2HTZrxK2hkBVo6GNCmCpYBL0QpK/N2QU02A9lcNfFkYqm
> LX+IERxyEd1z1oNust3svRr5NKU3BEbdfXblAYtUIORTws+YDkZrc7SyksdCSIOa
> az7mmTxDcR/uQ8K/7SVO/D3nlutZm8MkYb5gFCbBaI7O5rmRACDMgYGlh0vCZ2dL
> tes0YBlsTBPWcHxb+/y6IsFs6HEZrPKPAQUu4wPJmcRb8PuJ95gxwUODSmf2duxL
> HJOWkci/j/ViNmJ/paVuI5MpJyHUMBf6oo/ze1IkL/4PKK2b4+drvyCY9KwV7Mjn
> dLsMDuJV/i959NkJa4EE
> =+Uu8
> -----END PGP SIGNATURE-----
>
> --Sig_/T.+7iMvUwEH92u+UTGF86Po--
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger•kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2014-11-25 20:55 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 5:46 linux-next: manual merge of the tip tree with the pm tree Stephen Rothwell
2014-11-25 21:16 ` Rafael J. Wysocki [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-06-03 13:32 Mark Brown
2026-06-04 12:33 ` Frederic Weisbecker
2026-05-25 14:16 Mark Brown
2026-02-04 13:52 Mark Brown
2026-02-04 14:48 ` Wysocki, Rafael J
2026-02-04 14:56 ` Sebastian Andrzej Siewior
2025-05-16 6:15 Stephen Rothwell
2025-05-16 7:54 ` Ingo Molnar
2025-05-16 9:54 ` Stephen Rothwell
2025-05-16 12:45 ` Ingo Molnar
2025-05-28 3:52 ` Stephen Rothwell
2025-05-12 4:55 Stephen Rothwell
2025-05-12 5:23 ` Stephen Rothwell
2025-05-12 20:45 ` Mario Limonciello
2025-05-15 15:49 ` Ingo Molnar
2025-05-15 15:50 ` Mario Limonciello
2025-05-28 3:50 ` Stephen Rothwell
2025-05-28 14:14 ` Limonciello, Mario
2025-05-28 22:12 ` Stephen Rothwell
2025-05-01 3:58 Stephen Rothwell
2025-05-06 15:07 ` Wysocki, Rafael J
2025-05-06 17:43 ` Ingo Molnar
2025-04-17 3:43 Stephen Rothwell
2025-04-17 11:22 ` Ingo Molnar
2024-07-02 4:15 Stephen Rothwell
2024-07-02 9:25 ` Borislav Petkov
2024-07-17 1:41 ` Stephen Rothwell
2024-07-17 2:33 ` srinivas pandruvada
2024-07-17 9:49 ` Borislav Petkov
2024-06-24 17:06 Mark Brown
2024-06-25 3:00 ` Xiaojian Du
2024-06-25 4:25 ` Borislav Petkov
2024-06-25 4:51 ` Xiaojian Du
2021-02-17 5:07 Stephen Rothwell
2021-02-17 10:15 ` Andy Shevchenko
2021-02-22 0:34 ` Stephen Rothwell
2018-10-08 2:44 Stephen Rothwell
2018-10-08 10:06 ` Rafael J. Wysocki
2018-10-08 10:34 ` Andy Shevchenko
2018-10-08 2:40 Stephen Rothwell
2018-10-08 10:05 ` Rafael J. Wysocki
2018-10-08 10:41 ` Andy Shevchenko
2018-03-23 2:20 Stephen Rothwell
2018-03-23 6:09 ` Ingo Molnar
2018-03-23 21:09 ` Rafael J. Wysocki
2018-03-24 8:15 ` Ingo Molnar
2017-11-06 2:10 Stephen Rothwell
2017-11-06 13:09 ` Rafael J. Wysocki
2017-08-11 4:06 Stephen Rothwell
2017-09-04 4:43 ` Stephen Rothwell
2016-11-22 5:48 Stephen Rothwell
2016-06-09 4:34 Stephen Rothwell
2016-04-19 2:59 Stephen Rothwell
2016-03-15 1:55 Stephen Rothwell
2016-03-11 1:57 Stephen Rothwell
2016-03-11 13:51 ` Rafael J. Wysocki
2016-02-29 4:42 Stephen Rothwell
2015-10-06 3:07 Stephen Rothwell
2015-03-31 7:58 Stephen Rothwell
2015-03-31 22:23 ` Rafael J. Wysocki
2015-03-31 7:10 Stephen Rothwell
2014-12-15 2:30 Stephen Rothwell
2014-08-04 6:55 Stephen Rothwell
2014-05-09 4:49 Stephen Rothwell
2014-01-13 3:29 Stephen Rothwell
2014-01-07 4:20 Stephen Rothwell
2014-01-06 7:18 Stephen Rothwell
2013-08-19 4:09 Stephen Rothwell
2013-04-11 4:08 Stephen Rothwell
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=1793317.oUQRzfcXxI@vostro.rjw.lan \
--to=rjw@rjwysocki$(echo .)net \
--cc=hanjun.guo@linaro$(echo .)org \
--cc=hpa@zytor$(echo .)com \
--cc=jiang.liu@linux$(echo .)intel.com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=peterz@infradead$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
--cc=yinghai@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox