* linux-next: manual merge of the tip tree with the pm tree
@ 2013-04-11 4:08 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2013-04-11 4:08 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Daniel Lezcano, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
include/linux/clockchips.h between commit 4dbad816febb ("timer: move enum
definition out of ifdef section") from the pm tree and commit
19919226c3f2 ("clockevents: Add missing tick_check_broadcast_expired()
for CLOCKEVENTS=n") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/clockchips.h
index f9fd937,464e229..0000000
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@@ -181,7 -192,8 +192,8 @@@ static inline void clockevents_notify(u
static inline void clockevents_suspend(void) {}
static inline void clockevents_resume(void) {}
-#define clockevents_notify(reason, arg) do { } while (0)
+static inline void clockevents_notify(unsigned long reason, void *arg) {}
+ static inline int tick_check_broadcast_expired(void) { return 0; }
#endif
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2013-08-19 4:09 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2013-08-19 4:09 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Stratos Karafotis, Rafael J. Wysocki,
Jason Wang
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/include/asm/processor.h between commit 61c63e5ed3b9 ("cpufreq:
Remove unused APERF/MPERF support") from the pm tree and commit
96e39ac0e9d1 ("x86: Introduce hypervisor_cpuid_base()") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/include/asm/processor.h
index 4f4a3d9,61a5533..0000000
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@@ -942,6 -942,50 +942,21 @@@ extern int set_tsc_mode(unsigned int va
extern u16 amd_get_nb_id(int cpu);
-struct aperfmperf {
- u64 aperf, mperf;
-};
-
-static inline void get_aperfmperf(struct aperfmperf *am)
-{
- WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_APERFMPERF));
-
- rdmsrl(MSR_IA32_APERF, am->aperf);
- rdmsrl(MSR_IA32_MPERF, am->mperf);
-}
-
-#define APERFMPERF_SHIFT 10
-
-static inline
-unsigned long calc_aperfmperf_ratio(struct aperfmperf *old,
- struct aperfmperf *new)
-{
- u64 aperf = new->aperf - old->aperf;
- u64 mperf = new->mperf - old->mperf;
- unsigned long ratio = aperf;
-
- mperf >>= APERFMPERF_SHIFT;
- if (mperf)
- ratio = div64_u64(aperf, mperf);
-
- return ratio;
-}
-
+ static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+ {
+ uint32_t base, eax, signature[3];
+
+ for (base = 0x40000000; base < 0x40010000; base += 0x100) {
+ cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
+
+ if (!memcmp(sig, signature, 12) &&
+ (leaves == 0 || ((eax - base) >= leaves)))
+ return base;
+ }
+
+ return 0;
+ }
+
extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-06 7:18 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-01-06 7:18 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Chen, Gong, Borislav Petkov, Jiang Liu
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/acpi_extlog.c between commit 7ede9f8a1805 ("ACPI / extlog:
replace open-coded _DSM code with helper functions") from the pm tree and
commit 42139eb356e3 ("ACPI, eMCA: Combine eMCA/EDAC event reporting
priority") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/acpi/acpi_extlog.c
index 94166680b3a3,5d33c5415405..000000000000
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@@ -9,8 -9,10 +9,9 @@@
#include <linux/module.h>
#include <linux/acpi.h>
-#include <acpi/acpi_bus.h>
#include <linux/cper.h>
#include <linux/ratelimit.h>
+ #include <linux/edac.h>
#include <asm/cpu.h>
#include <asm/mce.h>
@@@ -40,7 -44,9 +41,9 @@@ struct extlog_l1_head
u8 rev1[12];
};
+ static int old_edac_report_status;
+
-static u8 extlog_dsm_uuid[] = "663E35AF-CC10-41A4-88EA-5470AF055295";
+static u8 extlog_dsm_uuid[] __initdata = "663E35AF-CC10-41A4-88EA-5470AF055295";
/* L1 table related physical address */
static u64 elog_base;
@@@ -147,16 -153,53 +150,16 @@@ static int extlog_print(struct notifier
rc = print_extlog_rcd(NULL, (struct acpi_generic_status *)elog_buf, cpu);
- return NOTIFY_DONE;
+ return NOTIFY_STOP;
}
-static int extlog_get_dsm(acpi_handle handle, int rev, int func, u64 *ret)
+static bool __init extlog_get_l1addr(void)
{
- struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
- struct acpi_object_list input;
- union acpi_object params[4], *obj;
u8 uuid[16];
- int i;
+ acpi_handle handle;
+ union acpi_object *obj;
acpi_str_to_uuid(extlog_dsm_uuid, uuid);
- input.count = 4;
- input.pointer = params;
- params[0].type = ACPI_TYPE_BUFFER;
- params[0].buffer.length = 16;
- params[0].buffer.pointer = uuid;
- params[1].type = ACPI_TYPE_INTEGER;
- params[1].integer.value = rev;
- params[2].type = ACPI_TYPE_INTEGER;
- params[2].integer.value = func;
- params[3].type = ACPI_TYPE_PACKAGE;
- params[3].package.count = 0;
- params[3].package.elements = NULL;
-
- if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DSM", &input, &buf)))
- return -1;
-
- *ret = 0;
- obj = (union acpi_object *)buf.pointer;
- if (obj->type == ACPI_TYPE_INTEGER) {
- *ret = obj->integer.value;
- } else if (obj->type == ACPI_TYPE_BUFFER) {
- if (obj->buffer.length <= 8) {
- for (i = 0; i < obj->buffer.length; i++)
- *ret |= (obj->buffer.pointer[i] << (i * 8));
- }
- }
- kfree(buf.pointer);
-
- return 0;
-}
-
-static bool extlog_get_l1addr(void)
-{
- acpi_handle handle;
- u64 ret;
if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
return false;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-07 4:20 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-01-07 4:20 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Bartlomiej Zolnierkiewicz
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/processor_idle.c between commit 6cb85b2b9df9 ("ACPI /
cpuidle: fix max idle state handling with hotplug CPU support") from the
pm tree and commit 16824255394f ("x86, acpi, idle: Restructure the mwait
idle routines") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/acpi/processor_idle.c
index 1fc455b8ce17,f90c56c8379e..000000000000
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@@ -783,18 -780,6 +778,13 @@@ static int acpi_idle_enter_simple(struc
if (unlikely(!pr))
return -EINVAL;
+#ifdef CONFIG_HOTPLUG_CPU
+ if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
+ !pr->flags.has_cst &&
+ !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
+ return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START);
+#endif
+
- if (cx->entry_method == ACPI_CSTATE_FFH) {
- if (current_set_polling_and_test())
- return -EINVAL;
- }
-
/*
* Must be done before busmaster disable as we might need to
* access HPET !
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-13 3:29 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-01-13 3:29 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Lv Zheng, Chen, Gong, Borislav Petkov
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/apei/einj.c between commit 8b48463f8942 ("ACPI: Clean up
inclusions of ACPI header files") from the pm tree and commit
d3ab3edc029b ("ACPI, APEI: Cleanup alignment-aware accesses") from the
tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/acpi/apei/einj.c
index ca0c6d7ec0d4,7dcc8a824aae..000000000000
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@@ -33,6 -33,8 +33,7 @@@
#include <linux/nmi.h>
#include <linux/delay.h>
#include <linux/mm.h>
-#include <acpi/acpi.h>
+ #include <asm/unaligned.h>
#include "apei-internal.h"
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-05-09 4:49 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-05-09 4:49 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4723 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/sched/idle.c between commit 52c324f8a87b ("cpuidle: Combine
cpuidle_enabled() with cpuidle_select()") from the pm tree and commit
37352273ad48 ("sched/idle: Reflow cpuidle_idle_call()") from the tip
tree.
I fixed it up (I hope - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/sched/idle.c
index a8f12247ce7c,34083c9ac976..000000000000
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@@ -101,77 -98,74 +98,69 @@@ static void cpuidle_idle_call(void
rcu_idle_enter();
/*
- * Check if the cpuidle framework is ready, otherwise fallback
- * to the default arch specific idle method
+ * Ask the cpuidle framework to choose a convenient idle state.
+ * Fall back to the default arch specific idle method on errors.
*/
- if (cpuidle_enabled(drv, dev)) {
+ next_state = cpuidle_select(drv, dev);
+
- ret = next_state;
- if (ret >= 0) {
++ if (next_state < 0) {
+ use_default:
/*
- * The idle task must be scheduled, it is pointless to
- * go to idle, just update no idle residency and get
- * out of this function
+ * We can't use the cpuidle framework, let's use the default
+ * idle routine.
*/
- if (current_clr_polling_and_test()) {
- dev->last_residency = 0;
- entered_state = next_state;
+ if (current_clr_polling_and_test())
local_irq_enable();
- } else {
- broadcast = !!(drv->states[next_state].flags &
- CPUIDLE_FLAG_TIMER_STOP);
-
- if (broadcast)
- /*
- * Tell the time framework to switch
- * to a broadcast timer because our
- * local timer will be shutdown. If a
- * local timer is used from another
- * cpu as a broadcast timer, this call
- * may fail if it is not available
- */
- ret = clockevents_notify(
- CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
- &dev->cpu);
-
- if (ret >= 0) {
- trace_cpu_idle_rcuidle(next_state, dev->cpu);
-
- /*
- * Enter the idle state previously
- * returned by the governor
- * decision. This function will block
- * until an interrupt occurs and will
- * take care of re-enabling the local
- * interrupts
- */
- entered_state = cpuidle_enter(drv, dev,
- next_state);
-
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,
- dev->cpu);
-
- if (broadcast)
- clockevents_notify(
- CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
- &dev->cpu);
-
- /*
- * Give the governor an opportunity to reflect on the
- * outcome
- */
- cpuidle_reflect(dev, entered_state);
- }
- }
+ else
+ arch_cpu_idle();
+
+ goto exit_idle;
+ }
+
+ /*
- * Ask the governor to choose an idle state it thinks
- * it is convenient to go to. There is *always* a
- * convenient idle state
- */
- next_state = cpuidle_select(drv, dev);
-
- /*
+ * The idle task must be scheduled, it is pointless to
+ * go to idle, just update no idle residency and get
+ * out of this function
+ */
+ if (current_clr_polling_and_test()) {
+ dev->last_residency = 0;
+ entered_state = next_state;
+ local_irq_enable();
+ goto exit_idle;
}
+ broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
+
/*
- * We can't use the cpuidle framework, let's use the default
- * idle routine
+ * Tell the time framework to switch to a broadcast timer
+ * because our local timer will be shutdown. If a local timer
+ * is used from another cpu as a broadcast timer, this call may
+ * fail if it is not available
*/
- if (ret < 0)
- arch_cpu_idle();
+ if (broadcast &&
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
++ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu) < 0)
+ goto use_default;
+ trace_cpu_idle_rcuidle(next_state, dev->cpu);
+
+ /*
+ * Enter the idle state previously returned by the governor decision.
+ * This function will block until an interrupt occurs and will take
+ * care of re-enabling the local interrupts
+ */
+ entered_state = cpuidle_enter(drv, dev, next_state);
+
+ trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
+
+ if (broadcast)
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+
+ /*
+ * Give the governor an opportunity to reflect on the outcome
+ */
+ cpuidle_reflect(dev, entered_state);
+
+ exit_idle:
__current_set_polling();
/*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-08-04 6:55 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-08-04 6:55 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Tomasz Nowicki, Graeme Gregory,
Hanjun Guo
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/Kconfig between commit 8a1664be0b92 ("ACPI: add config for
BIOS table scan") from the pm tree and commit 44a69f619562 ("acpi, apei,
ghes: Make NMI error notification to be GHES architecture extension")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index ac5a788d2432,4559c4e114d1..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -133,7 -132,8 +133,9 @@@ config X8
select GENERIC_CPU_AUTOPROBE
select HAVE_ARCH_AUDITSYSCALL
select ARCH_SUPPORTS_ATOMIC_RMW
+ select ACPI_LEGACY_TABLES_LOOKUP if ACPI
+ select HAVE_ACPI_APEI if ACPI
+ select HAVE_ACPI_APEI_NMI if ACPI
config INSTRUCTION_DECODER
def_bool y
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-11-25 5:46 Stephen Rothwell
2014-11-25 21:16 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2014-11-25 5:46 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Hanjun Guo, Jiang Liu, Yinghai Lu
[-- Attachment #1: Type: text/plain, Size: 5475 bytes --]
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).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
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 = -1;
+ int phys_id = -1; /* CPU hardware ID */
+ struct acpi_table_madt *madt;
- if (!read_madt) {
- if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
- (struct acpi_table_header **)&madt)))
- madt = NULL;
- read_madt++;
- }
-
+ madt = get_madt_table();
if (!madt)
- return apic_id;
+ return phys_id;
entry = (unsigned long)madt;
madt_end = entry + madt->header.length;
@@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha
}
header = (struct acpi_subtable_header *)obj->buffer.pointer;
- if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
+ if (header->type == 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 == ACPI_MADT_TYPE_LOCAL_SAPIC) {
+ else if (header->type == 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 == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+ else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC)
- map_x2apic_id(header, type, acpi_id, &apic_id);
+ map_x2apic_id(header, type, acpi_id, &phys_id);
- }
exit:
kfree(buffer.pointer);
@@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp
int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
{
- int apic_id;
+ int phys_id;
- apic_id = acpi_get_apicid(handle, type, acpi_id);
+ phys_id = acpi_get_phys_id(handle, type, acpi_id);
- return acpi_map_cpuid(apic_id, acpi_id);
+ return acpi_map_cpuid(phys_id, acpi_id);
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+
+ #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 = (struct acpi_madt_io_apic *)entry;
+
+ if (ioapic->global_irq_base != gsi_base)
+ return 0;
+
+ *phys_addr = ioapic->address;
+ *ioapic_id = ioapic->id;
+ return 1;
+ }
+
+ 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 = -1;
+
+ madt = get_madt_table();
+ if (!madt)
+ return apic_id;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ hdr = (struct acpi_subtable_header *)entry;
+ if (hdr->type == ACPI_MADT_TYPE_IO_APIC &&
+ get_ioapic_id(hdr, gsi_base, phys_addr, &apic_id))
+ break;
+ else
+ entry += hdr->length;
+ }
+
+ return apic_id;
+ }
+
+ static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
+ u64 *phys_addr)
+ {
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_subtable_header *header;
+ union acpi_object *obj;
+ int apic_id = -1;
+
+ if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+ goto exit;
+
+ if (!buffer.length || !buffer.pointer)
+ goto exit;
+
+ obj = buffer.pointer;
+ if (obj->type != ACPI_TYPE_BUFFER ||
+ obj->buffer.length < sizeof(struct acpi_subtable_header))
+ goto exit;
+
+ header = (struct acpi_subtable_header *)obj->buffer.pointer;
+ if (header->type == ACPI_MADT_TYPE_IO_APIC)
+ get_ioapic_id(header, gsi_base, phys_addr, &apic_id);
+
+ exit:
+ kfree(buffer.pointer);
+ return apic_id;
+ }
+
+ /**
+ * 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 search
+ * for an ACPI IOAPIC record matching @gsi_base.
+ * Return IOAPIC id and store physical address in @phys_addr if found a match,
+ * otherwise return <0.
+ */
+ int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
+ {
+ int apic_id;
+
+ apic_id = parse_mat_ioapic_entry(handle, gsi_base, phys_addr);
+ if (apic_id == -1)
+ apic_id = parse_madt_ioapic_entry(gsi_base, phys_addr);
+
+ return apic_id;
+ }
+ #endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2014-11-25 5:46 Stephen Rothwell
@ 2014-11-25 21:16 ` Rafael J. Wysocki
0 siblings, 0 replies; 65+ messages in thread
From: Rafael J. Wysocki @ 2014-11-25 21:16 UTC (permalink / raw)
To: Stephen Rothwell, Hanjun Guo
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Jiang Liu, Yinghai Lu
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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2014-12-15 2:30 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2014-12-15 2:30 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/apic/io_apic.c between commit 16394fd03114 ("x86 / PM:
Replace CONFIG_PM_RUNTIME in io_apic.c") from the pm tree and various
commits from the tip tree.
I fixed it up (the tip tree seems to have made extensive changes to
this file and there are no longer any references to CONFIG_PM_RUNTIME,
so I used the tip tree version) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2015-03-31 7:10 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2015-03-31 7:10 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/arm/common/bL_switcher.c between commit bf03f36d239f ("arm:
bl_switcher: Kill tick suspend hackery") from the pm tree and commit
77e32c89a711 ("clockevents: Manage device's state separately for the
core") from the tip tree.
I fixed it up (the former removed all the code changed by the latter)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2015-03-31 7:58 Stephen Rothwell
2015-03-31 22:23 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2015-03-31 7:58 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 4225 bytes --]
Hi all,
Today's linux-next merge of the tip tree got conflicts in
include/linux/clockchips.h, kernel/time/tick-broadcast.c,
kernel/time/tick-common.c and kernel/time/tick-internal.h between
commit 01b9fdf7e540 ("tick: Move core only declarations and functions
to core") (and others) from the pm tree and commit 77e32c89a711
("clockevents: Manage device's state separately for the core") (and
others) from the tip tree.
I fixed it up (I *think* I may have figured it all out, but please
check - see below and teh final tree later) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/clockchips.h
index 4350d7101982,e20232c3320a..000000000000
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
diff --cc kernel/time/tick-broadcast.c
index f8e27cd0b7ab,f0f8ee9dbc28..000000000000
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@@ -553,9 -541,10 +553,9 @@@ static int tick_broadcast_set_event(str
return ret;
}
-int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
+static void tick_resume_broadcast_oneshot(struct clock_event_device *bc)
{
- clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
+ clockevents_set_state(bc, CLOCK_EVT_STATE_ONESHOT);
- return 0;
}
/*
diff --cc kernel/time/tick-common.c
index d9e769e31ee4,a5b877130ae9..000000000000
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@@ -386,19 -380,13 +387,20 @@@ void tick_suspend_local(void
clockevents_shutdown(td->evtdev);
}
-void tick_resume(void)
+/**
+ * tick_resume_local - Resume the local tick device
+ *
+ * Called from the local CPU for unfreeze or XEN resume magic.
+ *
+ * No locks required. Nothing can change the per cpu device.
+ */
+void tick_resume_local(void)
{
struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
- int broadcast = tick_resume_broadcast();
+ bool broadcast = tick_resume_check_broadcast();
- clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_RESUME);
+ clockevents_tick_resume(td->evtdev);
+
if (!broadcast) {
if (td->mode == TICKDEV_MODE_PERIODIC)
tick_setup_periodic(td->evtdev, 0);
diff --cc kernel/time/tick-internal.h
index 1c7560a533d5,98700e4a2000..000000000000
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@@ -27,31 -30,15 +27,32 @@@ extern void tick_resume(void)
extern bool tick_check_replacement(struct clock_event_device *curdev,
struct clock_event_device *newdev);
extern void tick_install_replacement(struct clock_event_device *dev);
+extern int tick_is_oneshot_available(void);
+extern struct tick_device *tick_get_device(int cpu);
+
+/* Check, if the device is functional or a dummy for broadcast */
+static inline int tick_device_is_functional(struct clock_event_device *dev)
+{
+ return !(dev->features & CLOCK_EVT_FEAT_DUMMY);
+}
extern void clockevents_shutdown(struct clock_event_device *dev);
+ extern int clockevents_tick_resume(struct clock_event_device *dev);
-
+extern void clockevents_exchange_device(struct clock_event_device *old,
+ struct clock_event_device *new);
- extern void clockevents_set_mode(struct clock_event_device *dev,
- enum clock_event_mode mode);
++extern void clockevents_set_state(struct clock_event_device *dev,
++ enum clock_event_state state);
+extern int clockevents_program_event(struct clock_event_device *dev,
+ ktime_t expires, bool force);
+extern void clockevents_handle_noop(struct clock_event_device *dev);
+extern int __clockevents_update_freq(struct clock_event_device *dev, u32 freq);
extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt);
+#else
+static inline void tick_suspend(void) { }
+static inline void tick_resume(void) { }
+#endif /* GENERIC_CLOCKEVENTS */
-/*
- * NO_HZ / high resolution timer shared code
- */
+/* Oneshot related functions */
#ifdef CONFIG_TICK_ONESHOT
extern void tick_setup_oneshot(struct clock_event_device *newdev,
void (*handler)(struct clock_event_device *),
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2015-03-31 7:58 Stephen Rothwell
@ 2015-03-31 22:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 65+ messages in thread
From: Rafael J. Wysocki @ 2015-03-31 22:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Tuesday, March 31, 2015 06:58:44 PM Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got conflicts in
> include/linux/clockchips.h, kernel/time/tick-broadcast.c,
> kernel/time/tick-common.c and kernel/time/tick-internal.h between
> commit 01b9fdf7e540 ("tick: Move core only declarations and functions
> to core") (and others) from the pm tree and commit 77e32c89a711
> ("clockevents: Manage device's state separately for the core") (and
> others) from the tip tree.
>
> I fixed it up (I *think* I may have figured it all out, but please
> check - see below and teh final tree later) and can carry the fix as
> necessary (no action is required).
The resolution looks good from the PM tree perspective, thanks!
Rafael
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2015-10-06 3:07 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2015-10-06 3:07 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Marc Zyngier, Jonathan (Zhixiong) Zhang
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/kernel/acpi.c
between commit:
f26527b1428f ("irqchip / GIC: Convert the GIC driver to ACPI probing")
from the pm tree and commit:
89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm64/kernel/acpi.c
index d6463bba2360,137d537ddceb..000000000000
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@@ -205,3 -210,52 +210,27 @@@ void __init acpi_boot_table_init(void
disable_acpi();
}
}
+
-void __init acpi_gic_init(void)
-{
- struct acpi_table_header *table;
- acpi_status status;
- acpi_size tbl_size;
- int err;
-
- if (acpi_disabled)
- return;
-
- status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
- if (ACPI_FAILURE(status)) {
- const char *msg = acpi_format_exception(status);
-
- pr_err("Failed to get MADT table, %s\n", msg);
- return;
- }
-
- err = gic_v2_acpi_init(table);
- if (err)
- pr_err("Failed to initialize GIC IRQ controller");
-
- early_acpi_os_unmap_memory((char *)table, tbl_size);
-}
-
+ #ifdef CONFIG_ACPI_APEI
+ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+ {
+ /*
+ * According to "Table 8 Map: EFI memory types to AArch64 memory
+ * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
+ * mapped to a corresponding MAIR attribute encoding.
+ * The EFI memory attribute advises all possible capabilities
+ * of a memory region. We use the most efficient capability.
+ */
+
+ u64 attr;
+
+ attr = efi_mem_attributes(addr);
+ if (attr & EFI_MEMORY_WB)
+ return PAGE_KERNEL;
+ if (attr & EFI_MEMORY_WT)
+ return __pgprot(PROT_NORMAL_WT);
+ if (attr & EFI_MEMORY_WC)
+ return __pgprot(PROT_NORMAL_NC);
+ return __pgprot(PROT_DEVICE_nGnRnE);
+ }
+ #endif
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-02-29 4:42 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2016-02-29 4:42 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Borislav Petkov, Srinivas Pandruvada
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/cpufreq/intel_pstate.c
between commit:
7791e4aa59ad ("cpufreq: intel_pstate: Enable HWP by default")
from the pm tree and commit:
bc696ca05f5a ("x86/cpufeature: Replace the old static_cpu_has() with safe variant")
from the tip tree.
I fixed it up (the former removed the code modified by the latter)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-03-11 1:57 Stephen Rothwell
2016-03-11 13:51 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2016-03-11 1:57 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/sched/sched.h
between commit:
adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory")
from the pm tree and commit:
e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell
diff --cc kernel/sched/sched.h
index faf7e2758dd0,e6d4a3fa3660..000000000000
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@@ -1739,50 -1794,15 +1794,63 @@@ static inline u64 irq_time_read(int cpu
#endif /* CONFIG_64BIT */
#endif /* CONFIG_IRQ_TIME_ACCOUNTING */
+#ifdef CONFIG_CPU_FREQ
+DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+
+/**
+ * cpufreq_update_util - Take a note about CPU utilization changes.
+ * @time: Current time.
+ * @util: Current utilization.
+ * @max: Utilization ceiling.
+ *
+ * This function is called by the scheduler on every invocation of
+ * update_load_avg() on the CPU whose utilization is being updated.
+ *
+ * It can only be called from RCU-sched read-side critical sections.
+ */
+static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+{
+ struct update_util_data *data;
+
+ data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
+ if (data)
+ data->func(data, time, util, max);
+}
+
+/**
+ * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
+ * @time: Current time.
+ *
+ * The way cpufreq is currently arranged requires it to evaluate the CPU
+ * performance state (frequency/voltage) on a regular basis to prevent it from
+ * being stuck in a completely inadequate performance level for too long.
+ * That is not guaranteed to happen if the updates are only triggered from CFS,
+ * though, because they may not be coming in if RT or deadline tasks are active
+ * all the time (or there are RT and DL tasks only).
+ *
+ * As a workaround for that issue, this function is called by the RT and DL
+ * sched classes to trigger extra cpufreq updates to prevent it from stalling,
+ * but that really is a band-aid. Going forward it should be replaced with
+ * solutions targeted more specifically at RT and DL tasks.
+ */
+static inline void cpufreq_trigger_update(u64 time)
+{
+ cpufreq_update_util(time, ULONG_MAX, 0);
+}
+#else
+static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) {}
+static inline void cpufreq_trigger_update(u64 time) {}
+#endif /* CONFIG_CPU_FREQ */
++
+ static inline void account_reset_rq(struct rq *rq)
+ {
+ #ifdef CONFIG_IRQ_TIME_ACCOUNTING
+ rq->prev_irq_time = 0;
+ #endif
+ #ifdef CONFIG_PARAVIRT
+ rq->prev_steal_time = 0;
+ #endif
+ #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
+ rq->prev_steal_time_rq = 0;
+ #endif
+ }
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2016-03-11 1:57 Stephen Rothwell
@ 2016-03-11 13:51 ` Rafael J. Wysocki
0 siblings, 0 replies; 65+ messages in thread
From: Rafael J. Wysocki @ 2016-03-11 13:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
On Friday, March 11, 2016 12:57:46 PM Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/sched/sched.h
>
> between commit:
>
> adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory")
>
> from the pm tree and commit:
>
> e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me, thanks!
Rafael
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-03-15 1:55 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2016-03-15 1:55 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Colin Ian King
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
tools/power/x86/turbostat/turbostat.c
between commit:
58cc30a4e608 ("tools/power turbostat: fix compiler warnings")
from the pm tree and commit:
1b69317d2dc8 ("tools/power turbostat: fix various build warnings")
from the tip tree.
I fixed it up (I arbitrarily used the pm tree version) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-04-19 2:59 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2016-04-19 2:59 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Borislav Petkov, Joe Perches
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/cpufreq/longhaul.c
between commit:
b49c22a6ca36 ("cpufreq: Convert printk(KERN_<LEVEL> to pr_<level>")
from the pm tree and commit:
93984fbd4e33 ("x86/cpufeature: Replace cpu_has_apic with boot_cpu_has() usage")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/cpufreq/longhaul.c
index beae5cf5c62c,247bfa8eaddb..000000000000
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@@ -932,8 -945,9 +932,8 @@@ static int __init longhaul_init(void
}
#endif
#ifdef CONFIG_X86_IO_APIC
- if (cpu_has_apic) {
+ if (boot_cpu_has(X86_FEATURE_APIC)) {
- printk(KERN_ERR PFX "APIC detected. Longhaul is currently "
- "broken in this configuration.\n");
+ pr_err("APIC detected. Longhaul is currently broken in this configuration.\n");
return -ENODEV;
}
#endif
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-06-09 4:34 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2016-06-09 4:34 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Jacob Pan, Dave Hansen
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/powercap/intel_rapl.c
between commit:
9b1d0794b70d ("powercap / RAPL: add support for Skylake-X")
from the pm tree and commit:
62d167330679 ("x86, powercap, rapl: Use Intel model macros intead of open-coding")
0bb04b5f2c24 ("x86, powercap, rapl: Reorder CPU detection table")
d40671e30cb4 ("x86, powercap, rapl: Add Skylake Server model number")
from the tip tree.
I fixed it up (I think that last tip tree commit does the same as the
pm tree one, so I used that) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2016-11-22 5:48 Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2016-11-22 5:48 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: linux-next, linux-kernel, Borislav Petkov, Len Brown, Wei Yongjun,
Arnd Bergmann
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/idle/Kconfig
drivers/idle/i7300_idle.c
between commits:
f2f31bb3f50b ("idle / i7300: Add CONFIG_PCI dependency")
ccd29e2ed6bc ("i7300_idle: avoid theoretical uninitialized data usage")
881ef1847b2d ("i7300_idle: fix typo in parameter description")
from the pm tree and commit:
b65ce83f2a60 ("i7300_idle: Remove this driver")
from the tip tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2017-08-11 4:06 Stephen Rothwell
2017-09-04 4:43 ` Stephen Rothwell
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2017-08-11 4:06 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Viresh Kumar
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/sched/fair.c
between commit:
674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
from the pm tree and commit:
a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/sched/fair.c
index d378d02fdfcb,8d5868771cb3..000000000000
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
+ static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
+ {
- if (&this_rq()->cfs == cfs_rq) {
++ struct rq *rq = rq_of(cfs_rq);
++
++ if (&rq->cfs == cfs_rq) {
+ /*
+ * There are a few boundary cases this might miss but it should
+ * get called often enough that that should (hopefully) not be
+ * a real problem -- added to that it only calls on the local
+ * CPU, so if we enqueue remotely we'll miss an update, but
+ * the next tick/schedule should update.
+ *
+ * It will not get called when we go idle, because the idle
+ * thread is a different class (!fair), nor will the utilization
+ * number include things like RT tasks.
+ *
+ * As is, the util number is not freq-invariant (we'd have to
+ * implement arch_scale_freq_capacity() for that).
+ *
+ * See cpu_util().
+ */
- cpufreq_update_util(rq_of(cfs_rq), 0);
++ cpufreq_update_util(rq, 0);
+ }
+ }
+
#ifdef CONFIG_SMP
/*
* Approximate:
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2017-08-11 4:06 Stephen Rothwell
@ 2017-09-04 4:43 ` Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2017-09-04 4:43 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Viresh Kumar
Hi all,
On Fri, 11 Aug 2017 14:06:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/sched/fair.c
>
> between commit:
>
> 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
>
> from the pm tree and commit:
>
> a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc kernel/sched/fair.c
> index d378d02fdfcb,8d5868771cb3..000000000000
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st
> }
> #endif /* CONFIG_FAIR_GROUP_SCHED */
>
> + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
> + {
> - if (&this_rq()->cfs == cfs_rq) {
> ++ struct rq *rq = rq_of(cfs_rq);
> ++
> ++ if (&rq->cfs == cfs_rq) {
> + /*
> + * There are a few boundary cases this might miss but it should
> + * get called often enough that that should (hopefully) not be
> + * a real problem -- added to that it only calls on the local
> + * CPU, so if we enqueue remotely we'll miss an update, but
> + * the next tick/schedule should update.
> + *
> + * It will not get called when we go idle, because the idle
> + * thread is a different class (!fair), nor will the utilization
> + * number include things like RT tasks.
> + *
> + * As is, the util number is not freq-invariant (we'd have to
> + * implement arch_scale_freq_capacity() for that).
> + *
> + * See cpu_util().
> + */
> - cpufreq_update_util(rq_of(cfs_rq), 0);
> ++ cpufreq_update_util(rq, 0);
> + }
> + }
> +
> #ifdef CONFIG_SMP
> /*
> * Approximate:
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2017-11-06 2:10 Stephen Rothwell
2017-11-06 13:09 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2017-11-06 2:10 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jason Baron,
Andy Lutomirski
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/idle/intel_idle.c
between commit:
0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)")
from the pm tree and commit:
675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/idle/intel_idle.c
index 5db5e3176f6a,f0b06b14e782..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -913,24 -913,19 +913,25 @@@ static __cpuidle int intel_idle(struct
struct cpuidle_state *state = &drv->states[index];
unsigned long eax = flg2MWAIT(state->flags);
unsigned int cstate;
+ bool uninitialized_var(tick);
+ int cpu = smp_processor_id();
- cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
-
/*
- * NB: if CPUIDLE_FLAG_TLB_FLUSHED is set, this idle transition
- * will probably flush the TLB. It's not guaranteed to flush
- * the TLB, though, so it's not clear that we can do anything
- * useful with this knowledge.
+ * leave_mm() to avoid costly and often unnecessary wakeups
+ * for flushing the user TLB's associated with the active mm.
*/
+ if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
+ leave_mm(cpu);
- if (!(lapic_timer_reliable_states & (1 << (cstate))))
- tick_broadcast_enter();
+ if (!static_cpu_has(X86_FEATURE_ARAT)) {
+ cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) &
+ MWAIT_CSTATE_MASK) + 1;
+ tick = false;
+ if (!(lapic_timer_reliable_states & (1 << (cstate)))) {
+ tick = true;
+ tick_broadcast_enter();
+ }
+ }
mwait_idle_with_hints(eax, ecx);
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2017-11-06 2:10 Stephen Rothwell
@ 2017-11-06 13:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 65+ messages in thread
From: Rafael J. Wysocki @ 2017-11-06 13:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux-Next Mailing List, Linux Kernel Mailing List, Jason Baron,
Andy Lutomirski
On Monday, November 6, 2017 3:10:40 AM CET Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/idle/intel_idle.c
>
> between commit:
>
> 0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)")
>
> from the pm tree and commit:
>
> 675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
The fix looks good to me, thanks!
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2018-03-23 2:20 Stephen Rothwell
2018-03-23 6:09 ` Ingo Molnar
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2018-03-23 2:20 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Claudio Scordino
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/sched/cpufreq_schedutil.c
between commit:
0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
from the pm tree and commit:
8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/sched/cpufreq_schedutil.c
index 04d3fe9ba7d2,89fe78ecb88c..000000000000
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@@ -280,11 -276,9 +286,11 @@@ static void sugov_update_single(struct
unsigned int next_f;
bool busy;
- sugov_set_iowait_boost(sg_cpu, time);
+ sugov_set_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
+ ignore_dl_rate_limit(sg_cpu, sg_policy);
+
if (!sugov_should_update_freq(sg_policy, time))
return;
@@@ -366,12 -353,7 +365,9 @@@ sugov_update_shared(struct update_util_
raw_spin_lock(&sg_policy->update_lock);
+ ignore_dl_rate_limit(sg_cpu, sg_policy);
+
- sugov_get_util(sg_cpu);
- sg_cpu->flags = flags;
-
- sugov_set_iowait_boost(sg_cpu, time);
+ sugov_set_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
if (sugov_should_update_freq(sg_policy, time)) {
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-03-23 2:20 Stephen Rothwell
@ 2018-03-23 6:09 ` Ingo Molnar
2018-03-23 21:09 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2018-03-23 6:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Linux-Next Mailing List,
Linux Kernel Mailing List, Claudio Scordino
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/sched/cpufreq_schedutil.c
>
> between commit:
>
> 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
Rafael, could you please send that to the scheduler tree?
Thanks,
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-03-23 6:09 ` Ingo Molnar
@ 2018-03-23 21:09 ` Rafael J. Wysocki
2018-03-24 8:15 ` Ingo Molnar
0 siblings, 1 reply; 65+ messages in thread
From: Rafael J. Wysocki @ 2018-03-23 21:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linux-Next Mailing List,
Linux Kernel Mailing List, Claudio Scordino
On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > kernel/sched/cpufreq_schedutil.c
> >
> > between commit:
> >
> > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
>
> Rafael, could you please send that to the scheduler tree?
You can apply from
https://patchwork.kernel.org/patch/10278127/
and I will drop it from my tree.
Thanks!
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-03-23 21:09 ` Rafael J. Wysocki
@ 2018-03-24 8:15 ` Ingo Molnar
0 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2018-03-24 8:15 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linux-Next Mailing List,
Linux Kernel Mailing List, Claudio Scordino
* Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi all,
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > kernel/sched/cpufreq_schedutil.c
> > >
> > > between commit:
> > >
> > > 0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
> >
> > Rafael, could you please send that to the scheduler tree?
>
> You can apply from
>
> https://patchwork.kernel.org/patch/10278127/
>
> and I will drop it from my tree.
>
> Thanks!
Great - Thomas picked it up and it's now in tip:sched/core:
e97a90f7069b: sched/cpufreq: Rate limits for SCHED_DEADLINE
and it should hit -next on Monday.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2018-10-08 2:40 Stephen Rothwell
2018-10-08 10:05 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2018-10-08 2:40 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andy Shevchenko
[-- Attachment #1: Type: text/plain, Size: 5265 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/idle/intel_idle.c
between commit:
a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
from the pm tree and commit:
f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/idle/intel_idle.c
index 791b8a366e6e,c4bb67ed8da3..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
.disable_promotion_to_c1e = true,
};
-#define ICPU(model, cpu) \
- { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
-
static const struct x86_cpu_id intel_idle_ids[] __initconst = {
- ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_NEHALEM, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_WESTMERE_EP, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom),
- ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft),
- ICPU(INTEL_FAM6_WESTMERE_EX, idle_cpu_nehalem),
- ICPU(INTEL_FAM6_SANDYBRIDGE, idle_cpu_snb),
- ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb),
- ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom),
- ICPU(INTEL_FAM6_ATOM_SILVERMONT, idle_cpu_byt),
- ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID, idle_cpu_tangier),
- ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht),
- ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb),
- ICPU(INTEL_FAM6_IVYBRIDGE_X, idle_cpu_ivt),
- ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw),
- ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw),
- ICPU(INTEL_FAM6_HASWELL_ULT, idle_cpu_hsw),
- ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw),
- ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn),
- ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
- ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
- ICPU(INTEL_FAM6_BROADWELL_X, idle_cpu_bdw),
- ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw),
- ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
- ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, idle_cpu_skl),
- ICPU(INTEL_FAM6_KABYLAKE_MOBILE, idle_cpu_skl),
- ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl),
- ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx),
- ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl),
- ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl),
- ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt),
- ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
- ICPU(INTEL_FAM6_ATOM_GOLDMONT_X, idle_cpu_dnv),
+ INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(WESTMERE, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem),
- INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom),
- INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft),
++ INTEL_CPU_FAM6(ATOM_BONNELL, idle_cpu_atom),
++ INTEL_CPU_FAM6(ATOM_BONNELL_MID, idle_cpu_lincroft),
+ INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
+ INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
+ INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb),
- INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom),
- INTEL_CPU_FAM6(ATOM_SILVERMONT1, idle_cpu_byt),
- INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom),
++ INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt),
++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier),
+ INTEL_CPU_FAM6(ATOM_AIRMONT, idle_cpu_cht),
+ INTEL_CPU_FAM6(IVYBRIDGE, idle_cpu_ivb),
+ INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt),
+ INTEL_CPU_FAM6(HASWELL_CORE, idle_cpu_hsw),
+ INTEL_CPU_FAM6(HASWELL_X, idle_cpu_hsw),
+ INTEL_CPU_FAM6(HASWELL_ULT, idle_cpu_hsw),
+ INTEL_CPU_FAM6(HASWELL_GT3E, idle_cpu_hsw),
- INTEL_CPU_FAM6(ATOM_SILVERMONT2, idle_cpu_avn),
++ INTEL_CPU_FAM6(ATOM_SILVERMONT_X, idle_cpu_avn),
+ INTEL_CPU_FAM6(BROADWELL_CORE, idle_cpu_bdw),
+ INTEL_CPU_FAM6(BROADWELL_GT3E, idle_cpu_bdw),
+ INTEL_CPU_FAM6(BROADWELL_X, idle_cpu_bdw),
+ INTEL_CPU_FAM6(BROADWELL_XEON_D, idle_cpu_bdw),
+ INTEL_CPU_FAM6(SKYLAKE_MOBILE, idle_cpu_skl),
+ INTEL_CPU_FAM6(SKYLAKE_DESKTOP, idle_cpu_skl),
+ INTEL_CPU_FAM6(KABYLAKE_MOBILE, idle_cpu_skl),
+ INTEL_CPU_FAM6(KABYLAKE_DESKTOP, idle_cpu_skl),
+ INTEL_CPU_FAM6(SKYLAKE_X, idle_cpu_skx),
+ INTEL_CPU_FAM6(XEON_PHI_KNL, idle_cpu_knl),
+ INTEL_CPU_FAM6(XEON_PHI_KNM, idle_cpu_knl),
+ INTEL_CPU_FAM6(ATOM_GOLDMONT, idle_cpu_bxt),
- INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, idle_cpu_bxt),
- INTEL_CPU_FAM6(ATOM_DENVERTON, idle_cpu_dnv),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, idle_cpu_dnv),
{}
};
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2018-10-08 2:44 Stephen Rothwell
2018-10-08 10:06 ` Rafael J. Wysocki
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2018-10-08 2:44 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andy Shevchenko
[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/powercap/intel_rapl.c
between commit:
17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")
from the pm tree and commit:
f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/powercap/intel_rapl.c
index bb92874b1175,8cbfcce57a06..000000000000
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
.compute_time_window = rapl_compute_time_window_atom,
};
-#define RAPL_CPU(_model, _ops) { \
- .vendor = X86_VENDOR_INTEL, \
- .family = 6, \
- .model = _model, \
- .driver_data = (kernel_ulong_t)&_ops, \
- }
-
static const struct x86_cpu_id rapl_ids[] __initconst = {
- RAPL_CPU(INTEL_FAM6_SANDYBRIDGE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core),
-
- RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X, rapl_defaults_core),
-
- RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_HASWELL_ULT, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server),
-
- RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_BROADWELL_X, rapl_defaults_hsw_server),
-
- RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server),
- RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core),
-
- RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT, rapl_defaults_byt),
- RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht),
- RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID, rapl_defaults_tng),
- RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann),
- RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
- RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X, rapl_defaults_core),
-
- RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server),
- RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server),
+ INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core),
+ INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core),
+
+ INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core),
+ INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core),
+
+ INTEL_CPU_FAM6(HASWELL_CORE, rapl_defaults_core),
+ INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core),
+ INTEL_CPU_FAM6(HASWELL_GT3E, rapl_defaults_core),
+ INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server),
+
+ INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core),
+ INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core),
+ INTEL_CPU_FAM6(BROADWELL_XEON_D, rapl_defaults_core),
+ INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server),
+
+ INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core),
+ INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core),
+ INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server),
+ INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core),
+ INTEL_CPU_FAM6(KABYLAKE_DESKTOP, rapl_defaults_core),
+ INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core),
+
- INTEL_CPU_FAM6(ATOM_SILVERMONT1, rapl_defaults_byt),
++ INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
+ INTEL_CPU_FAM6(ATOM_AIRMONT, rapl_defaults_cht),
- INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng),
- INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann),
++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
++ INTEL_CPU_FAM6(ATOM_AIRMONT_MID, rapl_defaults_ann),
+ INTEL_CPU_FAM6(ATOM_GOLDMONT, rapl_defaults_core),
- INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, rapl_defaults_core),
- INTEL_CPU_FAM6(ATOM_DENVERTON, rapl_defaults_core),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, rapl_defaults_core),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, rapl_defaults_core),
+
+ INTEL_CPU_FAM6(XEON_PHI_KNL, rapl_defaults_hsw_server),
+ INTEL_CPU_FAM6(XEON_PHI_KNM, rapl_defaults_hsw_server),
{}
};
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-10-08 2:40 Stephen Rothwell
@ 2018-10-08 10:05 ` Rafael J. Wysocki
2018-10-08 10:41 ` Andy Shevchenko
0 siblings, 1 reply; 65+ messages in thread
From: Rafael J. Wysocki @ 2018-10-08 10:05 UTC (permalink / raw)
To: Stephen Rothwell, Andy Shevchenko
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux-Next Mailing List, Linux Kernel Mailing List
On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote:
>
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> 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/idle/intel_idle.c
>
> between commit:
>
> a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
>
> from the pm tree and commit:
>
> f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --=20
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/idle/intel_idle.c
> index 791b8a366e6e,c4bb67ed8da3..000000000000
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
> .disable_promotion_to_c1e =3D true,
> };
> =20
> -#define ICPU(model, cpu) \
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
> -
> static const struct x86_cpu_id intel_idle_ids[] __initconst =3D {
> - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_NEHALEM, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_WESTMERE_EP, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom),
> - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft),
> - ICPU(INTEL_FAM6_WESTMERE_EX, idle_cpu_nehalem),
> - ICPU(INTEL_FAM6_SANDYBRIDGE, idle_cpu_snb),
> - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb),
> - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom),
> - ICPU(INTEL_FAM6_ATOM_SILVERMONT, idle_cpu_byt),
> - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID, idle_cpu_tangier),
> - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht),
> - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb),
> - ICPU(INTEL_FAM6_IVYBRIDGE_X, idle_cpu_ivt),
> - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw),
> - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw),
> - ICPU(INTEL_FAM6_HASWELL_ULT, idle_cpu_hsw),
> - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw),
> - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn),
> - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
> - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
> - ICPU(INTEL_FAM6_BROADWELL_X, idle_cpu_bdw),
> - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw),
> - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
> - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, idle_cpu_skl),
> - ICPU(INTEL_FAM6_KABYLAKE_MOBILE, idle_cpu_skl),
> - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl),
> - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx),
> - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl),
> - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl),
> - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt),
> - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X, idle_cpu_dnv),
> + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(WESTMERE, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem),
> - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom),
> - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft),
> ++ INTEL_CPU_FAM6(ATOM_BONNELL, idle_cpu_atom),
> ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID, idle_cpu_lincroft),
> + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
> + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
> + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb),
> - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom),
> - INTEL_CPU_FAM6(ATOM_SILVERMONT1, idle_cpu_byt),
> - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
> ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier),
> + INTEL_CPU_FAM6(ATOM_AIRMONT, idle_cpu_cht),
> + INTEL_CPU_FAM6(IVYBRIDGE, idle_cpu_ivb),
> + INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt),
> + INTEL_CPU_FAM6(HASWELL_CORE, idle_cpu_hsw),
> + INTEL_CPU_FAM6(HASWELL_X, idle_cpu_hsw),
> + INTEL_CPU_FAM6(HASWELL_ULT, idle_cpu_hsw),
> + INTEL_CPU_FAM6(HASWELL_GT3E, idle_cpu_hsw),
> - INTEL_CPU_FAM6(ATOM_SILVERMONT2, idle_cpu_avn),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_X, idle_cpu_avn),
> + INTEL_CPU_FAM6(BROADWELL_CORE, idle_cpu_bdw),
> + INTEL_CPU_FAM6(BROADWELL_GT3E, idle_cpu_bdw),
> + INTEL_CPU_FAM6(BROADWELL_X, idle_cpu_bdw),
> + INTEL_CPU_FAM6(BROADWELL_XEON_D, idle_cpu_bdw),
> + INTEL_CPU_FAM6(SKYLAKE_MOBILE, idle_cpu_skl),
> + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, idle_cpu_skl),
> + INTEL_CPU_FAM6(KABYLAKE_MOBILE, idle_cpu_skl),
> + INTEL_CPU_FAM6(KABYLAKE_DESKTOP, idle_cpu_skl),
> + INTEL_CPU_FAM6(SKYLAKE_X, idle_cpu_skx),
> + INTEL_CPU_FAM6(XEON_PHI_KNL, idle_cpu_knl),
> + INTEL_CPU_FAM6(XEON_PHI_KNM, idle_cpu_knl),
> + INTEL_CPU_FAM6(ATOM_GOLDMONT, idle_cpu_bxt),
> - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, idle_cpu_bxt),
> - INTEL_CPU_FAM6(ATOM_DENVERTON, idle_cpu_dnv),
> ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, idle_cpu_dnv),
> {}
> };
> =20
>
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
>
>
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6--
>
This looks good to me. Andy?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-10-08 2:44 Stephen Rothwell
@ 2018-10-08 10:06 ` Rafael J. Wysocki
2018-10-08 10:34 ` Andy Shevchenko
0 siblings, 1 reply; 65+ messages in thread
From: Rafael J. Wysocki @ 2018-10-08 10:06 UTC (permalink / raw)
To: Stephen Rothwell, Andy Shevchenko
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux-Next Mailing List, Linux Kernel Mailing List
On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote:
>
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> 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/powercap/intel_rapl.c
>
> between commit:
>
> 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")
>
> from the pm tree and commit:
>
> f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --=20
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/powercap/intel_rapl.c
> index bb92874b1175,8cbfcce57a06..000000000000
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
> .compute_time_window =3D rapl_compute_time_window_atom,
> };
> =20
> -#define RAPL_CPU(_model, _ops) { \
> - .vendor =3D X86_VENDOR_INTEL, \
> - .family =3D 6, \
> - .model =3D _model, \
> - .driver_data =3D (kernel_ulong_t)&_ops, \
> - }
> -
> static const struct x86_cpu_id rapl_ids[] __initconst =3D {
> - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core),
> -
> - RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X, rapl_defaults_core),
> -
> - RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_HASWELL_ULT, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server),
> -
> - RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_BROADWELL_X, rapl_defaults_hsw_server),
> -
> - RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server),
> - RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core),
> -
> - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT, rapl_defaults_byt),
> - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht),
> - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID, rapl_defaults_tng),
> - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann),
> - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
> - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X, rapl_defaults_core),
> -
> - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server),
> - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server),
> + INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core),
> + INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core),
> +
> + INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core),
> + INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core),
> +
> + INTEL_CPU_FAM6(HASWELL_CORE, rapl_defaults_core),
> + INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core),
> + INTEL_CPU_FAM6(HASWELL_GT3E, rapl_defaults_core),
> + INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server),
> +
> + INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core),
> + INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core),
> + INTEL_CPU_FAM6(BROADWELL_XEON_D, rapl_defaults_core),
> + INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server),
> +
> + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core),
> + INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core),
> + INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server),
> + INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core),
> + INTEL_CPU_FAM6(KABYLAKE_DESKTOP, rapl_defaults_core),
> + INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core),
> +
> - INTEL_CPU_FAM6(ATOM_SILVERMONT1, rapl_defaults_byt),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
> + INTEL_CPU_FAM6(ATOM_AIRMONT, rapl_defaults_cht),
> - INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng),
> - INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
> ++ INTEL_CPU_FAM6(ATOM_AIRMONT_MID, rapl_defaults_ann),
> + INTEL_CPU_FAM6(ATOM_GOLDMONT, rapl_defaults_core),
> - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, rapl_defaults_core),
> - INTEL_CPU_FAM6(ATOM_DENVERTON, rapl_defaults_core),
> ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, rapl_defaults_core),
> ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, rapl_defaults_core),
> +
> + INTEL_CPU_FAM6(XEON_PHI_KNL, rapl_defaults_hsw_server),
> + INTEL_CPU_FAM6(XEON_PHI_KNM, rapl_defaults_hsw_server),
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
>
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
>
>
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp--
This looks good to me too. Andy, any concerns?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-10-08 10:06 ` Rafael J. Wysocki
@ 2018-10-08 10:34 ` Andy Shevchenko
0 siblings, 0 replies; 65+ messages in thread
From: Andy Shevchenko @ 2018-10-08 10:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, Andy Shevchenko, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra (Intel), linux-next,
Linux Kernel Mailing List
On Mon, Oct 8, 2018 at 1:11 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote:
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> > 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/powercap/intel_rapl.c
> >
> > between commit:
> >
> > 17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")
> >
> > from the pm tree and commit:
> >
> > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --=20
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/powercap/intel_rapl.c
> > index bb92874b1175,8cbfcce57a06..000000000000
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
> > .compute_time_window =3D rapl_compute_time_window_atom,
> > };
> > =20
> > -#define RAPL_CPU(_model, _ops) { \
> > - .vendor =3D X86_VENDOR_INTEL, \
> > - .family =3D 6, \
> > - .model =3D _model, \
> > - .driver_data =3D (kernel_ulong_t)&_ops, \
> > - }
> > -
> > static const struct x86_cpu_id rapl_ids[] __initconst =3D {
> > - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X, rapl_defaults_core),
> > -
> > - RAPL_CPU(INTEL_FAM6_IVYBRIDGE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X, rapl_defaults_core),
> > -
> > - RAPL_CPU(INTEL_FAM6_HASWELL_CORE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_HASWELL_ULT, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_HASWELL_GT3E, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_HASWELL_X, rapl_defaults_hsw_server),
> > -
> > - RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_BROADWELL_X, rapl_defaults_hsw_server),
> > -
> > - RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_SKYLAKE_X, rapl_defaults_hsw_server),
> > - RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE, rapl_defaults_core),
> > -
> > - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT, rapl_defaults_byt),
> > - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT, rapl_defaults_cht),
> > - RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID, rapl_defaults_tng),
> > - RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID, rapl_defaults_ann),
> > - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
> > - RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X, rapl_defaults_core),
> > -
> > - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL, rapl_defaults_hsw_server),
> > - RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM, rapl_defaults_hsw_server),
> > + INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(SANDYBRIDGE_X, rapl_defaults_core),
> > +
> > + INTEL_CPU_FAM6(IVYBRIDGE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core),
> > +
> > + INTEL_CPU_FAM6(HASWELL_CORE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core),
> > + INTEL_CPU_FAM6(HASWELL_GT3E, rapl_defaults_core),
> > + INTEL_CPU_FAM6(HASWELL_X, rapl_defaults_hsw_server),
> > +
> > + INTEL_CPU_FAM6(BROADWELL_CORE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(BROADWELL_GT3E, rapl_defaults_core),
> > + INTEL_CPU_FAM6(BROADWELL_XEON_D, rapl_defaults_core),
> > + INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server),
> > +
> > + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core),
> > + INTEL_CPU_FAM6(SKYLAKE_MOBILE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(SKYLAKE_X, rapl_defaults_hsw_server),
> > + INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core),
> > + INTEL_CPU_FAM6(KABYLAKE_DESKTOP, rapl_defaults_core),
> > + INTEL_CPU_FAM6(CANNONLAKE_MOBILE, rapl_defaults_core),
> > +
> > - INTEL_CPU_FAM6(ATOM_SILVERMONT1, rapl_defaults_byt),
> > ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
> > + INTEL_CPU_FAM6(ATOM_AIRMONT, rapl_defaults_cht),
> > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng),
> > - INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann),
> > ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
> > ++ INTEL_CPU_FAM6(ATOM_AIRMONT_MID, rapl_defaults_ann),
> > + INTEL_CPU_FAM6(ATOM_GOLDMONT, rapl_defaults_core),
> > - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, rapl_defaults_core),
> > - INTEL_CPU_FAM6(ATOM_DENVERTON, rapl_defaults_core),
> > ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, rapl_defaults_core),
> > ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, rapl_defaults_core),
> > +
> > + INTEL_CPU_FAM6(XEON_PHI_KNL, rapl_defaults_hsw_server),
> > + INTEL_CPU_FAM6(XEON_PHI_KNM, rapl_defaults_hsw_server),
> > {}
> > };
> > MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> > Content-Type: application/pgp-signature
> > Content-Description: OpenPGP digital signature
> >
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp--
>
> This looks good to me too. Andy, any concerns?
Nope, looks good to me!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2018-10-08 10:05 ` Rafael J. Wysocki
@ 2018-10-08 10:41 ` Andy Shevchenko
0 siblings, 0 replies; 65+ messages in thread
From: Andy Shevchenko @ 2018-10-08 10:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linux-Next Mailing List,
Linux Kernel Mailing List
On Mon, Oct 08, 2018 at 12:05:02PM +0200, Rafael J. Wysocki wrote:
> On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote:
> >
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> > 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/idle/intel_idle.c
> >
> > between commit:
> >
> > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
> >
> > from the pm tree and commit:
> >
> > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --=20
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/idle/intel_idle.c
> > index 791b8a366e6e,c4bb67ed8da3..000000000000
> > --- a/drivers/idle/intel_idle.c
> > +++ b/drivers/idle/intel_idle.c
> > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
> > .disable_promotion_to_c1e =3D true,
> > };
> > =20
> > -#define ICPU(model, cpu) \
> > - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
> > -
> > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D {
> > - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_WESTMERE_EP, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom),
> > - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft),
> > - ICPU(INTEL_FAM6_WESTMERE_EX, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_SANDYBRIDGE, idle_cpu_snb),
> > - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb),
> > - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT, idle_cpu_byt),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID, idle_cpu_tangier),
> > - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht),
> > - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb),
> > - ICPU(INTEL_FAM6_IVYBRIDGE_X, idle_cpu_ivt),
> > - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_ULT, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn),
> > - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_X, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_KABYLAKE_MOBILE, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx),
> > - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl),
> > - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X, idle_cpu_dnv),
> > + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(WESTMERE, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem),
> > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom),
> > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft),
> > ++ INTEL_CPU_FAM6(ATOM_BONNELL, idle_cpu_atom),
> > ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID, idle_cpu_lincroft),
> > + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
> > + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb),
> > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom),
> > - INTEL_CPU_FAM6(ATOM_SILVERMONT1, idle_cpu_byt),
> > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
> > ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom),
> > ++ INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt),
> > ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier),
> > + INTEL_CPU_FAM6(ATOM_AIRMONT, idle_cpu_cht),
> > + INTEL_CPU_FAM6(IVYBRIDGE, idle_cpu_ivb),
> > + INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt),
> > + INTEL_CPU_FAM6(HASWELL_CORE, idle_cpu_hsw),
> > + INTEL_CPU_FAM6(HASWELL_X, idle_cpu_hsw),
> > + INTEL_CPU_FAM6(HASWELL_ULT, idle_cpu_hsw),
> > + INTEL_CPU_FAM6(HASWELL_GT3E, idle_cpu_hsw),
> > - INTEL_CPU_FAM6(ATOM_SILVERMONT2, idle_cpu_avn),
> > ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_X, idle_cpu_avn),
> > + INTEL_CPU_FAM6(BROADWELL_CORE, idle_cpu_bdw),
> > + INTEL_CPU_FAM6(BROADWELL_GT3E, idle_cpu_bdw),
> > + INTEL_CPU_FAM6(BROADWELL_X, idle_cpu_bdw),
> > + INTEL_CPU_FAM6(BROADWELL_XEON_D, idle_cpu_bdw),
> > + INTEL_CPU_FAM6(SKYLAKE_MOBILE, idle_cpu_skl),
> > + INTEL_CPU_FAM6(SKYLAKE_DESKTOP, idle_cpu_skl),
> > + INTEL_CPU_FAM6(KABYLAKE_MOBILE, idle_cpu_skl),
> > + INTEL_CPU_FAM6(KABYLAKE_DESKTOP, idle_cpu_skl),
> > + INTEL_CPU_FAM6(SKYLAKE_X, idle_cpu_skx),
> > + INTEL_CPU_FAM6(XEON_PHI_KNL, idle_cpu_knl),
> > + INTEL_CPU_FAM6(XEON_PHI_KNM, idle_cpu_knl),
> > + INTEL_CPU_FAM6(ATOM_GOLDMONT, idle_cpu_bxt),
> > - INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, idle_cpu_bxt),
> > - INTEL_CPU_FAM6(ATOM_DENVERTON, idle_cpu_dnv),
> > ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> > ++ INTEL_CPU_FAM6(ATOM_GOLDMONT_X, idle_cpu_dnv),
> > {}
> > };
> > =20
> >
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> > Content-Type: application/pgp-signature
> > Content-Description: OpenPGP digital signature
> >
> >
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6--
> >
>
> This looks good to me. Andy?
Either to me.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2021-02-17 5:07 Stephen Rothwell
2021-02-17 10:15 ` Andy Shevchenko
2021-02-22 0:34 ` Stephen Rothwell
0 siblings, 2 replies; 65+ messages in thread
From: Stephen Rothwell @ 2021-02-17 5:07 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Andy Shevchenko, Borislav Petkov, Linux Kernel Mailing List,
Linux Next Mailing List, Rafael J. Wysocki, Zheng Yongjun
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/platform/intel-mid/device_libs/platform_bt.c
between commit:
4590d98f5a4f ("sfi: Remove framework for deprecated firmware")
from the pm tree and commit:
bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")
from the tip tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2021-02-17 5:07 Stephen Rothwell
@ 2021-02-17 10:15 ` Andy Shevchenko
2021-02-22 0:34 ` Stephen Rothwell
1 sibling, 0 replies; 65+ messages in thread
From: Andy Shevchenko @ 2021-02-17 10:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Andy Shevchenko, Borislav Petkov,
Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki, Zheng Yongjun
On Wed, Feb 17, 2021 at 7:38 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/platform/intel-mid/device_libs/platform_bt.c
>
> between commit:
>
> 4590d98f5a4f ("sfi: Remove framework for deprecated firmware")
>
> from the pm tree and commit:
>
> bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")
>
> from the tip tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Yes, the file removal is the right thing to do.
Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2021-02-17 5:07 Stephen Rothwell
2021-02-17 10:15 ` Andy Shevchenko
@ 2021-02-22 0:34 ` Stephen Rothwell
1 sibling, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2021-02-22 0:34 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Andy Shevchenko, Borislav Petkov, Linux Kernel Mailing List,
Linux Next Mailing List, Rafael J. Wysocki, Zheng Yongjun
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
Hi all,
On Wed, 17 Feb 2021 16:07:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/platform/intel-mid/device_libs/platform_bt.c
>
> between commit:
>
> 4590d98f5a4f ("sfi: Remove framework for deprecated firmware")
>
> from the pm tree and commit:
>
> bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")
>
> from the tip tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
This is now a conflict between the pm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2024-06-24 17:06 Mark Brown
2024-06-25 3:00 ` Xiaojian Du
0 siblings, 1 reply; 65+ messages in thread
From: Mark Brown @ 2024-06-24 17:06 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Borislav Petkov, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Xiaojian Du
[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/include/asm/cpufeatures.h
between commit:
c7107750b2ffa ("x86/cpufeatures: Add AMD FAST CPPC feature flag")
from the pm tree and commit:
78ce84b9e0a54 ("x86/cpufeatures: Flip the /proc/cpuinfo appearance logic")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc arch/x86/include/asm/cpufeatures.h
index 6c128d463a143,6007462e03d66..0000000000000
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -465,12 -466,11 +466,12 @@@
*
* Reuse free bits when adding new feature flags!
*/
- #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* AMD LBR and PMC Freeze */
- #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */
- #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */
- #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */
- #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* "" Clear branch history at vmexit using SW loop */
- #define X86_FEATURE_FAST_CPPC (21*32 + 5) /* "" AMD Fast CPPC */
+ #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* "amd_lbr_pmc_freeze" AMD LBR and PMC Freeze */
+ #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* Clear branch history at syscall entry using SW loop */
+ #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* BHI_DIS_S HW control available */
+ #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* BHI_DIS_S HW control enabled */
+ #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch history at vmexit using SW loop */
++#define X86_FEATURE_FAST_CPPC (21*32 + 5) /* AMD Fast CPPC */
/*
* BUG word(s)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-06-24 17:06 Mark Brown
@ 2024-06-25 3:00 ` Xiaojian Du
2024-06-25 4:25 ` Borislav Petkov
0 siblings, 1 reply; 65+ messages in thread
From: Xiaojian Du @ 2024-06-25 3:00 UTC (permalink / raw)
To: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Borislav Petkov, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Xiaojian Du
Hi Mark,
Many thanks for your help.
On 2024/6/25 1:06, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/include/asm/cpufeatures.h
>
> between commit:
>
> c7107750b2ffa ("x86/cpufeatures: Add AMD FAST CPPC feature flag")
>
> from the pm tree and commit:
>
> 78ce84b9e0a54 ("x86/cpufeatures: Flip the /proc/cpuinfo appearance logic")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/x86/include/asm/cpufeatures.h
> index 6c128d463a143,6007462e03d66..0000000000000
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@@ -465,12 -466,11 +466,12 @@@
> *
> * Reuse free bits when adding new feature flags!
> */
> - #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* AMD LBR and PMC Freeze */
> - #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */
> - #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */
> - #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */
> - #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* "" Clear branch history at vmexit using SW loop */
> - #define X86_FEATURE_FAST_CPPC (21*32 + 5) /* "" AMD Fast CPPC */
> + #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* "amd_lbr_pmc_freeze" AMD LBR and PMC Freeze */
> + #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* Clear branch history at syscall entry using SW loop */
> + #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* BHI_DIS_S HW control available */
> + #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* BHI_DIS_S HW control enabled */
> + #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch history at vmexit using SW loop */
> ++#define X86_FEATURE_FAST_CPPC (21*32 + 5) /* AMD Fast CPPC */
>
But it is better to hide this new flag "Fast CPPC", prefer to use " /*
"" AMD Fast CPPC */ ".
Not expected that "CPPC" and "Fast CPPC" are listed to user at the same
time, it will cause confusion.
Thanks,
Xiaojian
> /*
> * BUG word(s)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-06-25 3:00 ` Xiaojian Du
@ 2024-06-25 4:25 ` Borislav Petkov
2024-06-25 4:51 ` Xiaojian Du
0 siblings, 1 reply; 65+ messages in thread
From: Borislav Petkov @ 2024-06-25 4:25 UTC (permalink / raw)
To: Xiaojian Du
Cc: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Xiaojian Du
On Tue, Jun 25, 2024 at 11:00:26AM +0800, Xiaojian Du wrote:
> But it is better to hide this new flag "Fast CPPC", prefer to use " /* ""
> AMD Fast CPPC */ ".
> Not expected that "CPPC" and "Fast CPPC" are listed to user at the same
> time, it will cause confusion.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/cpu&id=78ce84b9e0a54a0c91a7449f321c1f852c0cd3fc
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-06-25 4:25 ` Borislav Petkov
@ 2024-06-25 4:51 ` Xiaojian Du
0 siblings, 0 replies; 65+ messages in thread
From: Xiaojian Du @ 2024-06-25 4:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Xiaojian Du
Thanks for Borislav's comment.
Didn't check the recent change in "cpufeatures.h".
On 2024/6/25 12:25, Borislav Petkov wrote:
> On Tue, Jun 25, 2024 at 11:00:26AM +0800, Xiaojian Du wrote:
>> But it is better to hide this new flag "Fast CPPC", prefer to use " /* ""
>> AMD Fast CPPC */ ".
>> Not expected that "CPPC" and "Fast CPPC" are listed to user at the same
>> time, it will cause confusion.
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/cpu&id=78ce84b9e0a54a0c91a7449f321c1f852c0cd3fc
>
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2024-07-02 4:15 Stephen Rothwell
2024-07-02 9:25 ` Borislav Petkov
2024-07-17 1:41 ` Stephen Rothwell
0 siblings, 2 replies; 65+ messages in thread
From: Stephen Rothwell @ 2024-07-02 4:15 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Borislav Petkov (AMD), Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Srinivas Pandruvada, Xiaojian Du
[-- Attachment #1: Type: text/plain, Size: 15762 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/include/asm/cpufeatures.h
between commits:
c7107750b2ff ("x86/cpufeatures: Add AMD FAST CPPC feature flag")
7ea81936b853 ("x86/cpufeatures: Add HWP highest perf change feature flag")
from the pm tree and commit:
78ce84b9e0a5 ("x86/cpufeatures: Flip the /proc/cpuinfo appearance logic")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/include/asm/cpufeatures.h
index 0d99515530d3,6007462e03d6..000000000000
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -283,90 -283,89 +283,90 @@@
*
* Reuse free bits when adding new feature flags!
*/
- #define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */
- #define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* LLC occupancy monitoring */
- #define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* LLC Total MBM monitoring */
- #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */
- #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entry SWAPGS path */
- #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel entry SWAPGS path */
- #define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* #AC for split lock */
- #define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* "" Per-thread Memory Bandwidth Allocation */
- #define X86_FEATURE_SGX1 (11*32+ 8) /* "" Basic SGX */
- #define X86_FEATURE_SGX2 (11*32+ 9) /* "" SGX Enclave Dynamic Memory Management (EDMM) */
- #define X86_FEATURE_ENTRY_IBPB (11*32+10) /* "" Issue an IBPB on kernel entry */
- #define X86_FEATURE_RRSBA_CTRL (11*32+11) /* "" RET prediction control */
- #define X86_FEATURE_RETPOLINE (11*32+12) /* "" Generic Retpoline mitigation for Spectre variant 2 */
- #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* "" Use LFENCE for Spectre variant 2 */
- #define X86_FEATURE_RETHUNK (11*32+14) /* "" Use REturn THUNK */
- #define X86_FEATURE_UNRET (11*32+15) /* "" AMD BTB untrain return */
- #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */
- #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit when EIBRS is enabled */
- #define X86_FEATURE_SGX_EDECCSSA (11*32+18) /* "" SGX EDECCSSA user leaf function */
- #define X86_FEATURE_CALL_DEPTH (11*32+19) /* "" Call depth tracking for RSB stuffing */
- #define X86_FEATURE_MSR_TSX_CTRL (11*32+20) /* "" MSR IA32_TSX_CTRL (Intel) implemented */
- #define X86_FEATURE_SMBA (11*32+21) /* "" Slow Memory Bandwidth Allocation */
- #define X86_FEATURE_BMEC (11*32+22) /* "" Bandwidth Monitoring Event Configuration */
- #define X86_FEATURE_USER_SHSTK (11*32+23) /* Shadow stack support for user mode applications */
- #define X86_FEATURE_SRSO (11*32+24) /* "" AMD BTB untrain RETs */
- #define X86_FEATURE_SRSO_ALIAS (11*32+25) /* "" AMD BTB untrain RETs through aliasing */
- #define X86_FEATURE_IBPB_ON_VMEXIT (11*32+26) /* "" Issue an IBPB only on VMEXIT */
- #define X86_FEATURE_APIC_MSRS_FENCE (11*32+27) /* "" IA32_TSC_DEADLINE and X2APIC MSRs need fencing */
- #define X86_FEATURE_ZEN2 (11*32+28) /* "" CPU based on Zen2 microarchitecture */
- #define X86_FEATURE_ZEN3 (11*32+29) /* "" CPU based on Zen3 microarchitecture */
- #define X86_FEATURE_ZEN4 (11*32+30) /* "" CPU based on Zen4 microarchitecture */
- #define X86_FEATURE_ZEN1 (11*32+31) /* "" CPU based on Zen1 microarchitecture */
+ #define X86_FEATURE_CQM_LLC (11*32+ 0) /* "cqm_llc" LLC QoS if 1 */
+ #define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* "cqm_occup_llc" LLC occupancy monitoring */
+ #define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* "cqm_mbm_total" LLC Total MBM monitoring */
+ #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* "cqm_mbm_local" LLC Local MBM monitoring */
+ #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* LFENCE in user entry SWAPGS path */
+ #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* LFENCE in kernel entry SWAPGS path */
+ #define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* "split_lock_detect" #AC for split lock */
+ #define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* Per-thread Memory Bandwidth Allocation */
+ #define X86_FEATURE_SGX1 (11*32+ 8) /* Basic SGX */
+ #define X86_FEATURE_SGX2 (11*32+ 9) /* SGX Enclave Dynamic Memory Management (EDMM) */
+ #define X86_FEATURE_ENTRY_IBPB (11*32+10) /* Issue an IBPB on kernel entry */
+ #define X86_FEATURE_RRSBA_CTRL (11*32+11) /* RET prediction control */
+ #define X86_FEATURE_RETPOLINE (11*32+12) /* Generic Retpoline mitigation for Spectre variant 2 */
+ #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* Use LFENCE for Spectre variant 2 */
+ #define X86_FEATURE_RETHUNK (11*32+14) /* Use REturn THUNK */
+ #define X86_FEATURE_UNRET (11*32+15) /* AMD BTB untrain return */
+ #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* Use IBPB during runtime firmware calls */
+ #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* Fill RSB on VM exit when EIBRS is enabled */
+ #define X86_FEATURE_SGX_EDECCSSA (11*32+18) /* SGX EDECCSSA user leaf function */
+ #define X86_FEATURE_CALL_DEPTH (11*32+19) /* Call depth tracking for RSB stuffing */
+ #define X86_FEATURE_MSR_TSX_CTRL (11*32+20) /* MSR IA32_TSX_CTRL (Intel) implemented */
+ #define X86_FEATURE_SMBA (11*32+21) /* Slow Memory Bandwidth Allocation */
+ #define X86_FEATURE_BMEC (11*32+22) /* Bandwidth Monitoring Event Configuration */
+ #define X86_FEATURE_USER_SHSTK (11*32+23) /* "user_shstk" Shadow stack support for user mode applications */
+ #define X86_FEATURE_SRSO (11*32+24) /* AMD BTB untrain RETs */
+ #define X86_FEATURE_SRSO_ALIAS (11*32+25) /* AMD BTB untrain RETs through aliasing */
+ #define X86_FEATURE_IBPB_ON_VMEXIT (11*32+26) /* Issue an IBPB only on VMEXIT */
+ #define X86_FEATURE_APIC_MSRS_FENCE (11*32+27) /* IA32_TSC_DEADLINE and X2APIC MSRs need fencing */
+ #define X86_FEATURE_ZEN2 (11*32+28) /* CPU based on Zen2 microarchitecture */
+ #define X86_FEATURE_ZEN3 (11*32+29) /* CPU based on Zen3 microarchitecture */
+ #define X86_FEATURE_ZEN4 (11*32+30) /* CPU based on Zen4 microarchitecture */
+ #define X86_FEATURE_ZEN1 (11*32+31) /* CPU based on Zen1 microarchitecture */
/* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
- #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */
- #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */
- #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* "" CMPccXADD instructions */
- #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* "" Intel Architectural PerfMon Extension */
- #define X86_FEATURE_FZRM (12*32+10) /* "" Fast zero-length REP MOVSB */
- #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */
- #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */
- #define X86_FEATURE_FRED (12*32+17) /* Flexible Return and Event Delivery */
- #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */
- #define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-serializing WRMSR */
- #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */
- #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMADD52[H,L]UQ */
- #define X86_FEATURE_LAM (12*32+26) /* Linear Address Masking */
+ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
+ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
+ #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */
+ #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* Intel Architectural PerfMon Extension */
+ #define X86_FEATURE_FZRM (12*32+10) /* Fast zero-length REP MOVSB */
+ #define X86_FEATURE_FSRS (12*32+11) /* Fast short REP STOSB */
+ #define X86_FEATURE_FSRC (12*32+12) /* Fast short REP {CMPSB,SCASB} */
+ #define X86_FEATURE_FRED (12*32+17) /* "fred" Flexible Return and Event Delivery */
+ #define X86_FEATURE_LKGS (12*32+18) /* Load "kernel" (userspace) GS */
+ #define X86_FEATURE_WRMSRNS (12*32+19) /* Non-serializing WRMSR */
+ #define X86_FEATURE_AMX_FP16 (12*32+21) /* AMX fp16 Support */
+ #define X86_FEATURE_AVX_IFMA (12*32+23) /* Support for VPMADD52[H,L]UQ */
+ #define X86_FEATURE_LAM (12*32+26) /* "lam" Linear Address Masking */
/* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
- #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */
- #define X86_FEATURE_IRPERF (13*32+ 1) /* Instructions Retired Count */
- #define X86_FEATURE_XSAVEERPTR (13*32+ 2) /* Always save/restore FP error pointers */
- #define X86_FEATURE_RDPRU (13*32+ 4) /* Read processor register at user level */
- #define X86_FEATURE_WBNOINVD (13*32+ 9) /* WBNOINVD instruction */
- #define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch Prediction Barrier */
- #define X86_FEATURE_AMD_IBRS (13*32+14) /* "" Indirect Branch Restricted Speculation */
- #define X86_FEATURE_AMD_STIBP (13*32+15) /* "" Single Thread Indirect Branch Predictors */
- #define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* "" Single Thread Indirect Branch Predictors always-on preferred */
- #define X86_FEATURE_AMD_PPIN (13*32+23) /* Protected Processor Inventory Number */
- #define X86_FEATURE_AMD_SSBD (13*32+24) /* "" Speculative Store Bypass Disable */
- #define X86_FEATURE_VIRT_SSBD (13*32+25) /* Virtualized Speculative Store Bypass Disable */
- #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* "" Speculative Store Bypass is fixed in hardware. */
- #define X86_FEATURE_CPPC (13*32+27) /* Collaborative Processor Performance Control */
- #define X86_FEATURE_AMD_PSFD (13*32+28) /* "" Predictive Store Forwarding Disable */
- #define X86_FEATURE_BTC_NO (13*32+29) /* "" Not vulnerable to Branch Type Confusion */
- #define X86_FEATURE_BRS (13*32+31) /* Branch Sampling available */
+ #define X86_FEATURE_CLZERO (13*32+ 0) /* "clzero" CLZERO instruction */
+ #define X86_FEATURE_IRPERF (13*32+ 1) /* "irperf" Instructions Retired Count */
+ #define X86_FEATURE_XSAVEERPTR (13*32+ 2) /* "xsaveerptr" Always save/restore FP error pointers */
+ #define X86_FEATURE_RDPRU (13*32+ 4) /* "rdpru" Read processor register at user level */
+ #define X86_FEATURE_WBNOINVD (13*32+ 9) /* "wbnoinvd" WBNOINVD instruction */
+ #define X86_FEATURE_AMD_IBPB (13*32+12) /* Indirect Branch Prediction Barrier */
+ #define X86_FEATURE_AMD_IBRS (13*32+14) /* Indirect Branch Restricted Speculation */
+ #define X86_FEATURE_AMD_STIBP (13*32+15) /* Single Thread Indirect Branch Predictors */
+ #define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
+ #define X86_FEATURE_AMD_PPIN (13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
+ #define X86_FEATURE_AMD_SSBD (13*32+24) /* Speculative Store Bypass Disable */
+ #define X86_FEATURE_VIRT_SSBD (13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
+ #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* Speculative Store Bypass is fixed in hardware. */
+ #define X86_FEATURE_CPPC (13*32+27) /* "cppc" Collaborative Processor Performance Control */
+ #define X86_FEATURE_AMD_PSFD (13*32+28) /* Predictive Store Forwarding Disable */
+ #define X86_FEATURE_BTC_NO (13*32+29) /* Not vulnerable to Branch Type Confusion */
+ #define X86_FEATURE_BRS (13*32+31) /* "brs" Branch Sampling available */
/* Thermal and Power Management Leaf, CPUID level 0x00000006 (EAX), word 14 */
- #define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */
- #define X86_FEATURE_IDA (14*32+ 1) /* Intel Dynamic Acceleration */
- #define X86_FEATURE_ARAT (14*32+ 2) /* Always Running APIC Timer */
- #define X86_FEATURE_PLN (14*32+ 4) /* Intel Power Limit Notification */
- #define X86_FEATURE_PTS (14*32+ 6) /* Intel Package Thermal Status */
- #define X86_FEATURE_HWP (14*32+ 7) /* Intel Hardware P-states */
- #define X86_FEATURE_HWP_NOTIFY (14*32+ 8) /* HWP Notification */
- #define X86_FEATURE_HWP_ACT_WINDOW (14*32+ 9) /* HWP Activity Window */
- #define X86_FEATURE_HWP_EPP (14*32+10) /* HWP Energy Perf. Preference */
- #define X86_FEATURE_HWP_PKG_REQ (14*32+11) /* HWP Package Level Request */
- #define X86_FEATURE_HWP_HIGHEST_PERF_CHANGE (14*32+15) /* "" HWP Highest perf change */
- #define X86_FEATURE_HFI (14*32+19) /* Hardware Feedback Interface */
+ #define X86_FEATURE_DTHERM (14*32+ 0) /* "dtherm" Digital Thermal Sensor */
+ #define X86_FEATURE_IDA (14*32+ 1) /* "ida" Intel Dynamic Acceleration */
+ #define X86_FEATURE_ARAT (14*32+ 2) /* "arat" Always Running APIC Timer */
+ #define X86_FEATURE_PLN (14*32+ 4) /* "pln" Intel Power Limit Notification */
+ #define X86_FEATURE_PTS (14*32+ 6) /* "pts" Intel Package Thermal Status */
+ #define X86_FEATURE_HWP (14*32+ 7) /* "hwp" Intel Hardware P-states */
+ #define X86_FEATURE_HWP_NOTIFY (14*32+ 8) /* "hwp_notify" HWP Notification */
+ #define X86_FEATURE_HWP_ACT_WINDOW (14*32+ 9) /* "hwp_act_window" HWP Activity Window */
+ #define X86_FEATURE_HWP_EPP (14*32+10) /* "hwp_epp" HWP Energy Perf. Preference */
+ #define X86_FEATURE_HWP_PKG_REQ (14*32+11) /* "hwp_pkg_req" HWP Package Level Request */
++#define X86_FEATURE_HWP_HIGHEST_PERF_CHANGE (14*32+15) /* HWP Highest perf change */
+ #define X86_FEATURE_HFI (14*32+19) /* "hfi" Hardware Feedback Interface */
/* AMD SVM Feature Identification, CPUID level 0x8000000a (EDX), word 15 */
- #define X86_FEATURE_NPT (15*32+ 0) /* Nested Page Table support */
- #define X86_FEATURE_LBRV (15*32+ 1) /* LBR Virtualization support */
+ #define X86_FEATURE_NPT (15*32+ 0) /* "npt" Nested Page Table support */
+ #define X86_FEATURE_LBRV (15*32+ 1) /* "lbrv" LBR Virtualization support */
#define X86_FEATURE_SVML (15*32+ 2) /* "svm_lock" SVM locking MSR */
#define X86_FEATURE_NRIPS (15*32+ 3) /* "nrip_save" SVM next_rip save */
#define X86_FEATURE_TSCRATEMSR (15*32+ 4) /* "tsc_scale" TSC scaling support */
@@@ -466,12 -466,11 +467,12 @@@
*
* Reuse free bits when adding new feature flags!
*/
- #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* AMD LBR and PMC Freeze */
- #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */
- #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */
- #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */
- #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* "" Clear branch history at vmexit using SW loop */
- #define X86_FEATURE_FAST_CPPC (21*32 + 5) /* "" AMD Fast CPPC */
+ #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* "amd_lbr_pmc_freeze" AMD LBR and PMC Freeze */
+ #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* Clear branch history at syscall entry using SW loop */
+ #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* BHI_DIS_S HW control available */
+ #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* BHI_DIS_S HW control enabled */
+ #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch history at vmexit using SW loop */
++#define X86_FEATURE_FAST_CPPC (21*32 + 5) /* AMD Fast CPPC */
/*
* BUG word(s)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-07-02 4:15 Stephen Rothwell
@ 2024-07-02 9:25 ` Borislav Petkov
2024-07-17 1:41 ` Stephen Rothwell
1 sibling, 0 replies; 65+ messages in thread
From: Borislav Petkov @ 2024-07-02 9:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Srinivas Pandruvada, Xiaojian Du
On Tue, Jul 02, 2024 at 02:15:55PM +1000, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks, LGTM.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
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
1 sibling, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2024-07-17 1:41 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Borislav Petkov (AMD), Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Srinivas Pandruvada, Xiaojian Du
[-- Attachment #1: Type: text/plain, Size: 16376 bytes --]
Hi all,
On Tue, 2 Jul 2024 14:15:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/include/asm/cpufeatures.h
>
> between commits:
>
> c7107750b2ff ("x86/cpufeatures: Add AMD FAST CPPC feature flag")
> 7ea81936b853 ("x86/cpufeatures: Add HWP highest perf change feature flag")
>
> from the pm tree and commit:
>
> 78ce84b9e0a5 ("x86/cpufeatures: Flip the /proc/cpuinfo appearance logic")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/include/asm/cpufeatures.h
> index 0d99515530d3,6007462e03d6..000000000000
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@@ -283,90 -283,89 +283,90 @@@
> *
> * Reuse free bits when adding new feature flags!
> */
> - #define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */
> - #define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* LLC occupancy monitoring */
> - #define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* LLC Total MBM monitoring */
> - #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */
> - #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entry SWAPGS path */
> - #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel entry SWAPGS path */
> - #define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* #AC for split lock */
> - #define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* "" Per-thread Memory Bandwidth Allocation */
> - #define X86_FEATURE_SGX1 (11*32+ 8) /* "" Basic SGX */
> - #define X86_FEATURE_SGX2 (11*32+ 9) /* "" SGX Enclave Dynamic Memory Management (EDMM) */
> - #define X86_FEATURE_ENTRY_IBPB (11*32+10) /* "" Issue an IBPB on kernel entry */
> - #define X86_FEATURE_RRSBA_CTRL (11*32+11) /* "" RET prediction control */
> - #define X86_FEATURE_RETPOLINE (11*32+12) /* "" Generic Retpoline mitigation for Spectre variant 2 */
> - #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* "" Use LFENCE for Spectre variant 2 */
> - #define X86_FEATURE_RETHUNK (11*32+14) /* "" Use REturn THUNK */
> - #define X86_FEATURE_UNRET (11*32+15) /* "" AMD BTB untrain return */
> - #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */
> - #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit when EIBRS is enabled */
> - #define X86_FEATURE_SGX_EDECCSSA (11*32+18) /* "" SGX EDECCSSA user leaf function */
> - #define X86_FEATURE_CALL_DEPTH (11*32+19) /* "" Call depth tracking for RSB stuffing */
> - #define X86_FEATURE_MSR_TSX_CTRL (11*32+20) /* "" MSR IA32_TSX_CTRL (Intel) implemented */
> - #define X86_FEATURE_SMBA (11*32+21) /* "" Slow Memory Bandwidth Allocation */
> - #define X86_FEATURE_BMEC (11*32+22) /* "" Bandwidth Monitoring Event Configuration */
> - #define X86_FEATURE_USER_SHSTK (11*32+23) /* Shadow stack support for user mode applications */
> - #define X86_FEATURE_SRSO (11*32+24) /* "" AMD BTB untrain RETs */
> - #define X86_FEATURE_SRSO_ALIAS (11*32+25) /* "" AMD BTB untrain RETs through aliasing */
> - #define X86_FEATURE_IBPB_ON_VMEXIT (11*32+26) /* "" Issue an IBPB only on VMEXIT */
> - #define X86_FEATURE_APIC_MSRS_FENCE (11*32+27) /* "" IA32_TSC_DEADLINE and X2APIC MSRs need fencing */
> - #define X86_FEATURE_ZEN2 (11*32+28) /* "" CPU based on Zen2 microarchitecture */
> - #define X86_FEATURE_ZEN3 (11*32+29) /* "" CPU based on Zen3 microarchitecture */
> - #define X86_FEATURE_ZEN4 (11*32+30) /* "" CPU based on Zen4 microarchitecture */
> - #define X86_FEATURE_ZEN1 (11*32+31) /* "" CPU based on Zen1 microarchitecture */
> + #define X86_FEATURE_CQM_LLC (11*32+ 0) /* "cqm_llc" LLC QoS if 1 */
> + #define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* "cqm_occup_llc" LLC occupancy monitoring */
> + #define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* "cqm_mbm_total" LLC Total MBM monitoring */
> + #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* "cqm_mbm_local" LLC Local MBM monitoring */
> + #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* LFENCE in user entry SWAPGS path */
> + #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* LFENCE in kernel entry SWAPGS path */
> + #define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* "split_lock_detect" #AC for split lock */
> + #define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* Per-thread Memory Bandwidth Allocation */
> + #define X86_FEATURE_SGX1 (11*32+ 8) /* Basic SGX */
> + #define X86_FEATURE_SGX2 (11*32+ 9) /* SGX Enclave Dynamic Memory Management (EDMM) */
> + #define X86_FEATURE_ENTRY_IBPB (11*32+10) /* Issue an IBPB on kernel entry */
> + #define X86_FEATURE_RRSBA_CTRL (11*32+11) /* RET prediction control */
> + #define X86_FEATURE_RETPOLINE (11*32+12) /* Generic Retpoline mitigation for Spectre variant 2 */
> + #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* Use LFENCE for Spectre variant 2 */
> + #define X86_FEATURE_RETHUNK (11*32+14) /* Use REturn THUNK */
> + #define X86_FEATURE_UNRET (11*32+15) /* AMD BTB untrain return */
> + #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* Use IBPB during runtime firmware calls */
> + #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* Fill RSB on VM exit when EIBRS is enabled */
> + #define X86_FEATURE_SGX_EDECCSSA (11*32+18) /* SGX EDECCSSA user leaf function */
> + #define X86_FEATURE_CALL_DEPTH (11*32+19) /* Call depth tracking for RSB stuffing */
> + #define X86_FEATURE_MSR_TSX_CTRL (11*32+20) /* MSR IA32_TSX_CTRL (Intel) implemented */
> + #define X86_FEATURE_SMBA (11*32+21) /* Slow Memory Bandwidth Allocation */
> + #define X86_FEATURE_BMEC (11*32+22) /* Bandwidth Monitoring Event Configuration */
> + #define X86_FEATURE_USER_SHSTK (11*32+23) /* "user_shstk" Shadow stack support for user mode applications */
> + #define X86_FEATURE_SRSO (11*32+24) /* AMD BTB untrain RETs */
> + #define X86_FEATURE_SRSO_ALIAS (11*32+25) /* AMD BTB untrain RETs through aliasing */
> + #define X86_FEATURE_IBPB_ON_VMEXIT (11*32+26) /* Issue an IBPB only on VMEXIT */
> + #define X86_FEATURE_APIC_MSRS_FENCE (11*32+27) /* IA32_TSC_DEADLINE and X2APIC MSRs need fencing */
> + #define X86_FEATURE_ZEN2 (11*32+28) /* CPU based on Zen2 microarchitecture */
> + #define X86_FEATURE_ZEN3 (11*32+29) /* CPU based on Zen3 microarchitecture */
> + #define X86_FEATURE_ZEN4 (11*32+30) /* CPU based on Zen4 microarchitecture */
> + #define X86_FEATURE_ZEN1 (11*32+31) /* CPU based on Zen1 microarchitecture */
>
> /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
> - #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */
> - #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instructions */
> - #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* "" CMPccXADD instructions */
> - #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* "" Intel Architectural PerfMon Extension */
> - #define X86_FEATURE_FZRM (12*32+10) /* "" Fast zero-length REP MOVSB */
> - #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */
> - #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */
> - #define X86_FEATURE_FRED (12*32+17) /* Flexible Return and Event Delivery */
> - #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */
> - #define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-serializing WRMSR */
> - #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */
> - #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMADD52[H,L]UQ */
> - #define X86_FEATURE_LAM (12*32+26) /* Linear Address Masking */
> + #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
> + #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
> + #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructions */
> + #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* Intel Architectural PerfMon Extension */
> + #define X86_FEATURE_FZRM (12*32+10) /* Fast zero-length REP MOVSB */
> + #define X86_FEATURE_FSRS (12*32+11) /* Fast short REP STOSB */
> + #define X86_FEATURE_FSRC (12*32+12) /* Fast short REP {CMPSB,SCASB} */
> + #define X86_FEATURE_FRED (12*32+17) /* "fred" Flexible Return and Event Delivery */
> + #define X86_FEATURE_LKGS (12*32+18) /* Load "kernel" (userspace) GS */
> + #define X86_FEATURE_WRMSRNS (12*32+19) /* Non-serializing WRMSR */
> + #define X86_FEATURE_AMX_FP16 (12*32+21) /* AMX fp16 Support */
> + #define X86_FEATURE_AVX_IFMA (12*32+23) /* Support for VPMADD52[H,L]UQ */
> + #define X86_FEATURE_LAM (12*32+26) /* "lam" Linear Address Masking */
>
> /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
> - #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */
> - #define X86_FEATURE_IRPERF (13*32+ 1) /* Instructions Retired Count */
> - #define X86_FEATURE_XSAVEERPTR (13*32+ 2) /* Always save/restore FP error pointers */
> - #define X86_FEATURE_RDPRU (13*32+ 4) /* Read processor register at user level */
> - #define X86_FEATURE_WBNOINVD (13*32+ 9) /* WBNOINVD instruction */
> - #define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch Prediction Barrier */
> - #define X86_FEATURE_AMD_IBRS (13*32+14) /* "" Indirect Branch Restricted Speculation */
> - #define X86_FEATURE_AMD_STIBP (13*32+15) /* "" Single Thread Indirect Branch Predictors */
> - #define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* "" Single Thread Indirect Branch Predictors always-on preferred */
> - #define X86_FEATURE_AMD_PPIN (13*32+23) /* Protected Processor Inventory Number */
> - #define X86_FEATURE_AMD_SSBD (13*32+24) /* "" Speculative Store Bypass Disable */
> - #define X86_FEATURE_VIRT_SSBD (13*32+25) /* Virtualized Speculative Store Bypass Disable */
> - #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* "" Speculative Store Bypass is fixed in hardware. */
> - #define X86_FEATURE_CPPC (13*32+27) /* Collaborative Processor Performance Control */
> - #define X86_FEATURE_AMD_PSFD (13*32+28) /* "" Predictive Store Forwarding Disable */
> - #define X86_FEATURE_BTC_NO (13*32+29) /* "" Not vulnerable to Branch Type Confusion */
> - #define X86_FEATURE_BRS (13*32+31) /* Branch Sampling available */
> + #define X86_FEATURE_CLZERO (13*32+ 0) /* "clzero" CLZERO instruction */
> + #define X86_FEATURE_IRPERF (13*32+ 1) /* "irperf" Instructions Retired Count */
> + #define X86_FEATURE_XSAVEERPTR (13*32+ 2) /* "xsaveerptr" Always save/restore FP error pointers */
> + #define X86_FEATURE_RDPRU (13*32+ 4) /* "rdpru" Read processor register at user level */
> + #define X86_FEATURE_WBNOINVD (13*32+ 9) /* "wbnoinvd" WBNOINVD instruction */
> + #define X86_FEATURE_AMD_IBPB (13*32+12) /* Indirect Branch Prediction Barrier */
> + #define X86_FEATURE_AMD_IBRS (13*32+14) /* Indirect Branch Restricted Speculation */
> + #define X86_FEATURE_AMD_STIBP (13*32+15) /* Single Thread Indirect Branch Predictors */
> + #define X86_FEATURE_AMD_STIBP_ALWAYS_ON (13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
> + #define X86_FEATURE_AMD_PPIN (13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
> + #define X86_FEATURE_AMD_SSBD (13*32+24) /* Speculative Store Bypass Disable */
> + #define X86_FEATURE_VIRT_SSBD (13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
> + #define X86_FEATURE_AMD_SSB_NO (13*32+26) /* Speculative Store Bypass is fixed in hardware. */
> + #define X86_FEATURE_CPPC (13*32+27) /* "cppc" Collaborative Processor Performance Control */
> + #define X86_FEATURE_AMD_PSFD (13*32+28) /* Predictive Store Forwarding Disable */
> + #define X86_FEATURE_BTC_NO (13*32+29) /* Not vulnerable to Branch Type Confusion */
> + #define X86_FEATURE_BRS (13*32+31) /* "brs" Branch Sampling available */
>
> /* Thermal and Power Management Leaf, CPUID level 0x00000006 (EAX), word 14 */
> - #define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */
> - #define X86_FEATURE_IDA (14*32+ 1) /* Intel Dynamic Acceleration */
> - #define X86_FEATURE_ARAT (14*32+ 2) /* Always Running APIC Timer */
> - #define X86_FEATURE_PLN (14*32+ 4) /* Intel Power Limit Notification */
> - #define X86_FEATURE_PTS (14*32+ 6) /* Intel Package Thermal Status */
> - #define X86_FEATURE_HWP (14*32+ 7) /* Intel Hardware P-states */
> - #define X86_FEATURE_HWP_NOTIFY (14*32+ 8) /* HWP Notification */
> - #define X86_FEATURE_HWP_ACT_WINDOW (14*32+ 9) /* HWP Activity Window */
> - #define X86_FEATURE_HWP_EPP (14*32+10) /* HWP Energy Perf. Preference */
> - #define X86_FEATURE_HWP_PKG_REQ (14*32+11) /* HWP Package Level Request */
> - #define X86_FEATURE_HWP_HIGHEST_PERF_CHANGE (14*32+15) /* "" HWP Highest perf change */
> - #define X86_FEATURE_HFI (14*32+19) /* Hardware Feedback Interface */
> + #define X86_FEATURE_DTHERM (14*32+ 0) /* "dtherm" Digital Thermal Sensor */
> + #define X86_FEATURE_IDA (14*32+ 1) /* "ida" Intel Dynamic Acceleration */
> + #define X86_FEATURE_ARAT (14*32+ 2) /* "arat" Always Running APIC Timer */
> + #define X86_FEATURE_PLN (14*32+ 4) /* "pln" Intel Power Limit Notification */
> + #define X86_FEATURE_PTS (14*32+ 6) /* "pts" Intel Package Thermal Status */
> + #define X86_FEATURE_HWP (14*32+ 7) /* "hwp" Intel Hardware P-states */
> + #define X86_FEATURE_HWP_NOTIFY (14*32+ 8) /* "hwp_notify" HWP Notification */
> + #define X86_FEATURE_HWP_ACT_WINDOW (14*32+ 9) /* "hwp_act_window" HWP Activity Window */
> + #define X86_FEATURE_HWP_EPP (14*32+10) /* "hwp_epp" HWP Energy Perf. Preference */
> + #define X86_FEATURE_HWP_PKG_REQ (14*32+11) /* "hwp_pkg_req" HWP Package Level Request */
> ++#define X86_FEATURE_HWP_HIGHEST_PERF_CHANGE (14*32+15) /* HWP Highest perf change */
> + #define X86_FEATURE_HFI (14*32+19) /* "hfi" Hardware Feedback Interface */
>
> /* AMD SVM Feature Identification, CPUID level 0x8000000a (EDX), word 15 */
> - #define X86_FEATURE_NPT (15*32+ 0) /* Nested Page Table support */
> - #define X86_FEATURE_LBRV (15*32+ 1) /* LBR Virtualization support */
> + #define X86_FEATURE_NPT (15*32+ 0) /* "npt" Nested Page Table support */
> + #define X86_FEATURE_LBRV (15*32+ 1) /* "lbrv" LBR Virtualization support */
> #define X86_FEATURE_SVML (15*32+ 2) /* "svm_lock" SVM locking MSR */
> #define X86_FEATURE_NRIPS (15*32+ 3) /* "nrip_save" SVM next_rip save */
> #define X86_FEATURE_TSCRATEMSR (15*32+ 4) /* "tsc_scale" TSC scaling support */
> @@@ -466,12 -466,11 +467,12 @@@
> *
> * Reuse free bits when adding new feature flags!
> */
> - #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* AMD LBR and PMC Freeze */
> - #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* "" Clear branch history at syscall entry using SW loop */
> - #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* "" BHI_DIS_S HW control available */
> - #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* "" BHI_DIS_S HW control enabled */
> - #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* "" Clear branch history at vmexit using SW loop */
> - #define X86_FEATURE_FAST_CPPC (21*32 + 5) /* "" AMD Fast CPPC */
> + #define X86_FEATURE_AMD_LBR_PMC_FREEZE (21*32+ 0) /* "amd_lbr_pmc_freeze" AMD LBR and PMC Freeze */
> + #define X86_FEATURE_CLEAR_BHB_LOOP (21*32+ 1) /* Clear branch history at syscall entry using SW loop */
> + #define X86_FEATURE_BHI_CTRL (21*32+ 2) /* BHI_DIS_S HW control available */
> + #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* BHI_DIS_S HW control enabled */
> + #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch history at vmexit using SW loop */
> ++#define X86_FEATURE_FAST_CPPC (21*32 + 5) /* AMD Fast CPPC */
>
> /*
> * BUG word(s)
This is now a conflict between the pm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-07-17 1:41 ` Stephen Rothwell
@ 2024-07-17 2:33 ` srinivas pandruvada
2024-07-17 9:49 ` Borislav Petkov
0 siblings, 1 reply; 65+ messages in thread
From: srinivas pandruvada @ 2024-07-17 2:33 UTC (permalink / raw)
To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Rafael J. Wysocki
Cc: Borislav Petkov (AMD), Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Xiaojian Du
On Wed, 2024-07-17 at 11:41 +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 2 Jul 2024 14:15:55 +1000 Stephen Rothwell
> <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/x86/include/asm/cpufeatures.h
> >
> > between commits:
> >
> > c7107750b2ff ("x86/cpufeatures: Add AMD FAST CPPC feature flag")
> > 7ea81936b853 ("x86/cpufeatures: Add HWP highest perf change
> > feature flag")
> >
> > from the pm tree and commit:
> >
> > 78ce84b9e0a5 ("x86/cpufeatures: Flip the /proc/cpuinfo appearance
> > logic")
> >
> > from the tip tree.
> >
> >
[...]
> > /*
> > * BUG word(s)
>
> This is now a conflict between the pm tree and Linus' tree.
>
linux-next branch of linux-pm tree needs to be rebased to Linus's tree.
This is the diff:
363a364
> #define X86_FEATURE_HWP_HIGHEST_PERF_CHANGE (14*32+15) /* "" HWP
Highest perf change */
472a474
> #define X86_FEATURE_FAST_CPPC (21*32 + 5) /* "" AMD Fast CPPC
*/
Thanks,
Srinivas
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2024-07-17 2:33 ` srinivas pandruvada
@ 2024-07-17 9:49 ` Borislav Petkov
0 siblings, 0 replies; 65+ messages in thread
From: Borislav Petkov @ 2024-07-17 9:49 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Rafael J. Wysocki, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Xiaojian Du
On Tue, Jul 16, 2024 at 07:33:12PM -0700, srinivas pandruvada wrote:
> linux-next branch of linux-pm tree needs to be rebased to Linus's tree.
Why?
You resolve the merge conflict and show Linus the resolution when sending the
pull request.
Rebasing is a no-no.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2025-04-17 3:43 Stephen Rothwell
2025-04-17 11:22 ` Ingo Molnar
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2025-04-17 3:43 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/cpufreq/acpi-cpufreq.c
between commit:
395b8b5c8f67 ("cpufreq: ACPI: Don't enable boost on policy exit")
from the pm tree and commit:
78255eb23973 ("x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/cpufreq/acpi-cpufreq.c
index 85b5a88f723f,8bc08f3b0d5d..000000000000
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@@ -108,17 -107,25 +108,17 @@@ static void boost_set_msr_each(void *p_
msr_mask = MSR_K7_HWCR_CPB_DIS;
break;
default:
- return -EINVAL;
+ return;
}
- rdmsrl(msr_addr, val);
+ rdmsrq(msr_addr, val);
if (enable)
val &= ~msr_mask;
else
val |= msr_mask;
- wrmsrl(msr_addr, val);
+ wrmsrq(msr_addr, val);
- return 0;
-}
-
-static void boost_set_msr_each(void *p_en)
-{
- bool enable = (bool) p_en;
-
- boost_set_msr(enable);
}
static int set_boost(struct cpufreq_policy *policy, int val)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-04-17 3:43 linux-next: manual merge of the tip tree with the pm tree Stephen Rothwell
@ 2025-04-17 11:22 ` Ingo Molnar
0 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2025-04-17 11:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Linux Kernel Mailing List,
Linux Next Mailing List, Rafael J. Wysocki, Viresh Kumar
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/cpufreq/acpi-cpufreq.c
>
> between commit:
>
> 395b8b5c8f67 ("cpufreq: ACPI: Don't enable boost on policy exit")
>
> from the pm tree and commit:
>
> 78255eb23973 ("x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
LGTM, thank you Stephen!
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2025-05-01 3:58 Stephen Rothwell
2025-05-06 15:07 ` Wysocki, Rafael J
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-01 3:58 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki, Srinivas Pandruvada
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/cpufreq/intel_pstate.c
between commit:
ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode")
from the pm tree and commit:
c435e608cf59 ("x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/cpufreq/intel_pstate.c
index 25830e5d76e8,2fc619ba6309..000000000000
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@@ -598,10 -598,7 +598,10 @@@ static bool turbo_is_disabled(void
{
u64 misc_en;
+ if (!cpu_feature_enabled(X86_FEATURE_IDA))
+ return true;
+
- rdmsrl(MSR_IA32_MISC_ENABLE, misc_en);
+ rdmsrq(MSR_IA32_MISC_ENABLE, misc_en);
return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-01 3:58 Stephen Rothwell
@ 2025-05-06 15:07 ` Wysocki, Rafael J
2025-05-06 17:43 ` Ingo Molnar
0 siblings, 1 reply; 65+ messages in thread
From: Wysocki, Rafael J @ 2025-05-06 15:07 UTC (permalink / raw)
To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Rafael J. Wysocki
Cc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,
Srinivas Pandruvada
Hi,
On 5/1/2025 5:58 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/cpufreq/intel_pstate.c
>
> between commit:
>
> ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode")
This one has been merged into 6.15-rc5.
> from the pm tree and commit:
>
> c435e608cf59 ("x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'")
So this one will clash with the mainline now.
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for the report!
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-06 15:07 ` Wysocki, Rafael J
@ 2025-05-06 17:43 ` Ingo Molnar
0 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2025-05-06 17:43 UTC (permalink / raw)
To: Wysocki, Rafael J
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Rafael J. Wysocki, Linux Kernel Mailing List,
Linux Next Mailing List, Srinivas Pandruvada
* Wysocki, Rafael J <rafael.j.wysocki@intel.com> wrote:
> > ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode")
>
> This one has been merged into 6.15-rc5.
>
>
> > from the pm tree and commit:
> >
> > c435e608cf59 ("x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'")
>
> So this one will clash with the mainline now.
Yeah - and I resolved it in tip:x86/msr:
commit 570d58b12fbf7bae0ba72d929ccf914a4df5ca7c (HEAD -> x86/msr)
Merge: 502ad6e5a619 92a09c47464d
Author: Ingo Molnar <mingo@kernel.org>
Date: Tue May 6 19:42:00 2025 +0200
Merge tag 'v6.15-rc5' into x86/msr, to pick up fixes and to resolve conflicts
Conflicts:
drivers/cpufreq/intel_pstate.c
Signed-off-by: Ingo Molnar <mingo@kernel.org>
So all should be good at this stage.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2025-05-12 4:55 Stephen Rothwell
2025-05-12 5:23 ` Stephen Rothwell
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-12 4:55 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/cpufreq/amd-pstate.c
between commit:
608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
from the pm tree and commit:
d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
from the tip tree.
I fixed it up (the former removed a line updated by the latter) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-12 4:55 Stephen Rothwell
@ 2025-05-12 5:23 ` Stephen Rothwell
2025-05-12 20:45 ` Mario Limonciello
2025-05-28 3:50 ` Stephen Rothwell
0 siblings, 2 replies; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-12 5:23 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello
[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]
Hi all,
On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/cpufreq/amd-pstate.c
>
> between commit:
>
> 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
>
> from the pm tree and commit:
>
> d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
>
> from the tip tree.
>
> I fixed it up (the former removed a line updated by the latter) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Actually it needed the fix up below.
--
Cheers,
Stephen Rothwell
diff --cc drivers/cpufreq/amd-pstate.c
index d96bb3e202ee,66fdc74f13ef..0d4c0de89a00
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@@ -389,10 -389,9 +389,10 @@@ static inline int amd_pstate_cppc_enabl
static int msr_init_perf(struct amd_cpudata *cpudata)
{
union perf_cached perf = READ_ONCE(cpudata->perf);
- u64 cap1, numerator;
+ u64 cap1, numerator, cppc_req;
+ u8 min_perf;
- int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
+ int ret = rdmsrq_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
&cap1);
if (ret)
return ret;
@@@ -401,22 -400,6 +401,22 @@@
if (ret)
return ret;
- ret = rdmsrl_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
++ ret = rdmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
+ if (ret)
+ return ret;
+
+ WRITE_ONCE(cpudata->cppc_req_cached, cppc_req);
+ min_perf = FIELD_GET(AMD_CPPC_MIN_PERF_MASK, cppc_req);
+
+ /*
+ * Clear out the min_perf part to check if the rest of the MSR is 0, if yes, this is an
+ * indication that the min_perf value is the one specified through the BIOS option
+ */
+ cppc_req &= ~(AMD_CPPC_MIN_PERF_MASK);
+
+ if (!cppc_req)
+ perf.bios_min_perf = min_perf;
+
perf.highest_perf = numerator;
perf.max_limit_perf = numerator;
perf.min_limit_perf = FIELD_GET(AMD_CPPC_LOWEST_PERF_MASK, cap1);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-12 5:23 ` Stephen Rothwell
@ 2025-05-12 20:45 ` Mario Limonciello
2025-05-15 15:49 ` Ingo Molnar
2025-05-28 3:50 ` Stephen Rothwell
1 sibling, 1 reply; 65+ messages in thread
From: Mario Limonciello @ 2025-05-12 20:45 UTC (permalink / raw)
To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Rafael J. Wysocki
Cc: Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List
On 5/12/2025 12:23 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the tip tree got a conflict in:
>>
>> drivers/cpufreq/amd-pstate.c
>>
>> between commit:
>>
>> 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
>>
>> from the pm tree and commit:
>>
>> d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
>>
>> from the tip tree.
>>
>> I fixed it up (the former removed a line updated by the latter) and can
>> carry the fix as necessary. This is now fixed as far as linux-next is
>> concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> Actually it needed the fix up below.
>
Ingo,
Can you guys make an immutable branch for Rafael to merge into linux-pm
for this change?
I can redo the amd-pstate merge based on that immutable branch.
Rafael,
If you want to just carry the fixup that's fine too. Just LMK what you
need.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-12 20:45 ` Mario Limonciello
@ 2025-05-15 15:49 ` Ingo Molnar
2025-05-15 15:50 ` Mario Limonciello
0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2025-05-15 15:49 UTC (permalink / raw)
To: Mario Limonciello
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List
* Mario Limonciello <mario.limonciello@amd.com> wrote:
> On 5/12/2025 12:23 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > drivers/cpufreq/amd-pstate.c
> > >
> > > between commit:
> > >
> > > 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
> > >
> > > from the pm tree and commit:
> > >
> > > d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
> > >
> > > from the tip tree.
> > >
> > > I fixed it up (the former removed a line updated by the latter) and can
> > > carry the fix as necessary. This is now fixed as far as linux-next is
> > > concerned, but any non trivial conflicts should be mentioned to your
> > > upstream maintainer when your tree is submitted for merging. You may
> > > also want to consider cooperating with the maintainer of the conflicting
> > > tree to minimise any particularly complex conflicts.
> >
> > Actually it needed the fix up below.
> >
>
> Ingo,
>
> Can you guys make an immutable branch for Rafael to merge into linux-pm for
> this change?
>
> I can redo the amd-pstate merge based on that immutable branch.
>
> Rafael,
>
> If you want to just carry the fixup that's fine too. Just LMK what you
> need.
If it's only about rdmsrl_on_cpu(), how about the simple compatibility
wrapper below instead, applied to the x86 tree?
Can merge it into -tip and tomorrow's -next would resolve this without
any changes or merges done to the PM tree.
Thanks,
Ingo
===============>
arch/x86/include/asm/msr.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index a9ce56fc8785..4096b8af4ba7 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -329,6 +329,7 @@ static inline int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8])
/* Compatibility wrappers: */
#define rdmsrl(msr, val) rdmsrq(msr, val)
#define wrmsrl(msr, val) wrmsrq(msr, val)
+#define rdmsrl_on_cpu(cpu, msr, q) rdmsrq_on_cpu(cpu, msr, q)
#endif /* __ASSEMBLER__ */
#endif /* _ASM_X86_MSR_H */
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-15 15:49 ` Ingo Molnar
@ 2025-05-15 15:50 ` Mario Limonciello
0 siblings, 0 replies; 65+ messages in thread
From: Mario Limonciello @ 2025-05-15 15:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List
On 5/15/2025 10:49 AM, Ingo Molnar wrote:
>
> * Mario Limonciello <mario.limonciello@amd.com> wrote:
>
>> On 5/12/2025 12:23 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> Today's linux-next merge of the tip tree got a conflict in:
>>>>
>>>> drivers/cpufreq/amd-pstate.c
>>>>
>>>> between commit:
>>>>
>>>> 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
>>>>
>>>> from the pm tree and commit:
>>>>
>>>> d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
>>>>
>>>> from the tip tree.
>>>>
>>>> I fixed it up (the former removed a line updated by the latter) and can
>>>> carry the fix as necessary. This is now fixed as far as linux-next is
>>>> concerned, but any non trivial conflicts should be mentioned to your
>>>> upstream maintainer when your tree is submitted for merging. You may
>>>> also want to consider cooperating with the maintainer of the conflicting
>>>> tree to minimise any particularly complex conflicts.
>>>
>>> Actually it needed the fix up below.
>>>
>>
>> Ingo,
>>
>> Can you guys make an immutable branch for Rafael to merge into linux-pm for
>> this change?
>>
>> I can redo the amd-pstate merge based on that immutable branch.
>>
>> Rafael,
>>
>> If you want to just carry the fixup that's fine too. Just LMK what you
>> need.
>
> If it's only about rdmsrl_on_cpu(), how about the simple compatibility
> wrapper below instead, applied to the x86 tree?
>
> Can merge it into -tip and tomorrow's -next would resolve this without
> any changes or merges done to the PM tree.
Sounds good to me.
>
> Thanks,
>
> Ingo
>
> ===============>
> arch/x86/include/asm/msr.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index a9ce56fc8785..4096b8af4ba7 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -329,6 +329,7 @@ static inline int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8])
> /* Compatibility wrappers: */
> #define rdmsrl(msr, val) rdmsrq(msr, val)
> #define wrmsrl(msr, val) wrmsrq(msr, val)
> +#define rdmsrl_on_cpu(cpu, msr, q) rdmsrq_on_cpu(cpu, msr, q)
>
> #endif /* __ASSEMBLER__ */
> #endif /* _ASM_X86_MSR_H */
^ permalink raw reply [flat|nested] 65+ messages in thread
* linux-next: manual merge of the tip tree with the pm tree
@ 2025-05-16 6:15 Stephen Rothwell
2025-05-16 7:54 ` Ingo Molnar
2025-05-28 3:52 ` Stephen Rothwell
0 siblings, 2 replies; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-16 6:15 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki
Cc: Ahmed S. Darwish, Artem Bityutskiy, Linux Kernel Mailing List,
Linux Next Mailing List, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/idle/intel_idle.c
between commit:
6138f3451516 ("intel_idle: Add C1 demotion on/off sysfs knob")
from the pm tree and commit:
968e30006807 ("x86/cpuid: Set <asm/cpuid/api.h> as the main CPUID header")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/idle/intel_idle.c
index 3292bf74e3c2,433d858b7be1..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -52,8 -51,7 +52,8 @@@
#include <linux/notifier.h>
#include <linux/cpu.h>
#include <linux/moduleparam.h>
+#include <linux/sysfs.h>
- #include <asm/cpuid.h>
+ #include <asm/cpuid/api.h>
#include <asm/cpu_device_id.h>
#include <asm/intel-family.h>
#include <asm/mwait.h>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-16 6:15 Stephen Rothwell
@ 2025-05-16 7:54 ` Ingo Molnar
2025-05-16 9:54 ` Stephen Rothwell
2025-05-28 3:52 ` Stephen Rothwell
1 sibling, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2025-05-16 7:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Ahmed S. Darwish, Artem Bityutskiy,
Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/idle/intel_idle.c
>
> between commit:
>
> 6138f3451516 ("intel_idle: Add C1 demotion on/off sysfs knob")
>
> from the pm tree and commit:
>
> 968e30006807 ("x86/cpuid: Set <asm/cpuid/api.h> as the main CPUID header")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/idle/intel_idle.c
> index 3292bf74e3c2,433d858b7be1..000000000000
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@@ -52,8 -51,7 +52,8 @@@
> #include <linux/notifier.h>
> #include <linux/cpu.h>
> #include <linux/moduleparam.h>
> +#include <linux/sysfs.h>
> - #include <asm/cpuid.h>
> + #include <asm/cpuid/api.h>
> #include <asm/cpu_device_id.h>
> #include <asm/intel-family.h>
> #include <asm/mwait.h>
So I don't think the <asm/cpuid.h> change is needed - the header still
fully exists:
starship:~/tip> ls -lh arch/x86/include/asm/cpuid/api.h arch/x86/include/asm/cpuid.h
-rw-rw-r-- 1 mingo mingo 6.1K May 16 09:34 arch/x86/include/asm/cpuid/api.h
-rw-rw-r-- 1 mingo mingo 149 May 16 09:34 arch/x86/include/asm/cpuid.h
And the <linux/sysfs.h> addition is probably a build fix for the PM
tree? The <asm/cpuid.h> header's indirect header dependencies did not
change. Should probably not be carried in -next, as this masks a build
failure that will then trigger in Linus's tree?
(Unless I'm missing something that is.)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-16 7:54 ` Ingo Molnar
@ 2025-05-16 9:54 ` Stephen Rothwell
2025-05-16 12:45 ` Ingo Molnar
0 siblings, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-16 9:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Ahmed S. Darwish, Artem Bityutskiy,
Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
Hi Ingo,
On Fri, 16 May 2025 09:54:35 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> So I don't think the <asm/cpuid.h> change is needed - the header still
> fully exists:
>
> starship:~/tip> ls -lh arch/x86/include/asm/cpuid/api.h arch/x86/include/asm/cpuid.h
> -rw-rw-r-- 1 mingo mingo 6.1K May 16 09:34 arch/x86/include/asm/cpuid/api.h
> -rw-rw-r-- 1 mingo mingo 149 May 16 09:34 arch/x86/include/asm/cpuid.h
That change is in the tip tree and involved in the conflict, so I just
used it as it was in the tip tree. This is normal conflict resolution.
> And the <linux/sysfs.h> addition is probably a build fix for the PM
> tree? The <asm/cpuid.h> header's indirect header dependencies did not
> change. Should probably not be carried in -next, as this masks a build
> failure that will then trigger in Linus's tree?
Well, it did not fail building yesterday (without the include) and
looks like the commit is adding the first sysfs use in this file ..
Mind you, if the sysfs.h include had been added a line or 2 higher up -
or even if there was a blank line between the linux/ and asm/ includes,
there may have been no conflict reported and git would have produced
the resulting file with both changes all by itself.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-16 9:54 ` Stephen Rothwell
@ 2025-05-16 12:45 ` Ingo Molnar
0 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2025-05-16 12:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Rafael J. Wysocki, Ahmed S. Darwish, Artem Bityutskiy,
Linux Kernel Mailing List, Linux Next Mailing List,
Rafael J. Wysocki
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Fri, 16 May 2025 09:54:35 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > So I don't think the <asm/cpuid.h> change is needed - the header still
> > fully exists:
> >
> > starship:~/tip> ls -lh arch/x86/include/asm/cpuid/api.h arch/x86/include/asm/cpuid.h
> > -rw-rw-r-- 1 mingo mingo 6.1K May 16 09:34 arch/x86/include/asm/cpuid/api.h
> > -rw-rw-r-- 1 mingo mingo 149 May 16 09:34 arch/x86/include/asm/cpuid.h
>
> That change is in the tip tree and involved in the conflict, so I
> just used it as it was in the tip tree. This is normal conflict
> resolution.
Yeah, indeed. I was somehow under the impression that there was a build
failure - but there wasn't.
It all looks good, sorry about the noise!
Thanks,
Ingo
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-12 5:23 ` Stephen Rothwell
2025-05-12 20:45 ` Mario Limonciello
@ 2025-05-28 3:50 ` Stephen Rothwell
2025-05-28 14:14 ` Limonciello, Mario
1 sibling, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-28 3:50 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Dhananjay Ugwekar, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
Hi all,
On Mon, 12 May 2025 15:23:26 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/cpufreq/amd-pstate.c
> >
> > between commit:
> >
> > 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
> >
> > from the pm tree and commit:
> >
> > d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
> >
> > from the tip tree.
> >
> > I fixed it up (the former removed a line updated by the latter) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
>
> Actually it needed the fix up below.
>
>
> diff --cc drivers/cpufreq/amd-pstate.c
> index d96bb3e202ee,66fdc74f13ef..0d4c0de89a00
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@@ -389,10 -389,9 +389,10 @@@ static inline int amd_pstate_cppc_enabl
> static int msr_init_perf(struct amd_cpudata *cpudata)
> {
> union perf_cached perf = READ_ONCE(cpudata->perf);
> - u64 cap1, numerator;
> + u64 cap1, numerator, cppc_req;
> + u8 min_perf;
>
> - int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
> + int ret = rdmsrq_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
> &cap1);
> if (ret)
> return ret;
> @@@ -401,22 -400,6 +401,22 @@@
> if (ret)
> return ret;
>
> - ret = rdmsrl_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
> ++ ret = rdmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
> + if (ret)
> + return ret;
> +
> + WRITE_ONCE(cpudata->cppc_req_cached, cppc_req);
> + min_perf = FIELD_GET(AMD_CPPC_MIN_PERF_MASK, cppc_req);
> +
> + /*
> + * Clear out the min_perf part to check if the rest of the MSR is 0, if yes, this is an
> + * indication that the min_perf value is the one specified through the BIOS option
> + */
> + cppc_req &= ~(AMD_CPPC_MIN_PERF_MASK);
> +
> + if (!cppc_req)
> + perf.bios_min_perf = min_perf;
> +
> perf.highest_perf = numerator;
> perf.max_limit_perf = numerator;
> perf.min_limit_perf = FIELD_GET(AMD_CPPC_LOWEST_PERF_MASK, cap1);
This is now a conflict between the pm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-16 6:15 Stephen Rothwell
2025-05-16 7:54 ` Ingo Molnar
@ 2025-05-28 3:52 ` Stephen Rothwell
1 sibling, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-28 3:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Ahmed S. Darwish, Artem Bityutskiy, Linux Kernel Mailing List,
Linux Next Mailing List, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
Hi all,
On Fri, 16 May 2025 16:15:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/idle/intel_idle.c
>
> between commit:
>
> 6138f3451516 ("intel_idle: Add C1 demotion on/off sysfs knob")
>
> from the pm tree and commit:
>
> 968e30006807 ("x86/cpuid: Set <asm/cpuid/api.h> as the main CPUID header")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc drivers/idle/intel_idle.c
> index 3292bf74e3c2,433d858b7be1..000000000000
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@@ -52,8 -51,7 +52,8 @@@
> #include <linux/notifier.h>
> #include <linux/cpu.h>
> #include <linux/moduleparam.h>
> +#include <linux/sysfs.h>
> - #include <asm/cpuid.h>
> + #include <asm/cpuid/api.h>
> #include <asm/cpu_device_id.h>
> #include <asm/intel-family.h>
> #include <asm/mwait.h>
This is now a conflict between the pm tree and Linus' tree
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-28 3:50 ` Stephen Rothwell
@ 2025-05-28 14:14 ` Limonciello, Mario
2025-05-28 22:12 ` Stephen Rothwell
0 siblings, 1 reply; 65+ messages in thread
From: Limonciello, Mario @ 2025-05-28 14:14 UTC (permalink / raw)
To: Stephen Rothwell, Rafael J. Wysocki, Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Ugwekar, Dhananjay, Linux Kernel Mailing List,
Linux Next Mailing List
On 5/27/25 22:50, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 12 May 2025 15:23:26 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> Today's linux-next merge of the tip tree got a conflict in:
>>>
>>> drivers/cpufreq/amd-pstate.c
>>>
>>> between commit:
>>>
>>> 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
>>>
>>> from the pm tree and commit:
>>>
>>> d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
>>>
>>> from the tip tree.
>>>
>>> I fixed it up (the former removed a line updated by the latter) and can
>>> carry the fix as necessary. This is now fixed as far as linux-next is
>>> concerned, but any non trivial conflicts should be mentioned to your
>>> upstream maintainer when your tree is submitted for merging. You may
>>> also want to consider cooperating with the maintainer of the conflicting
>>> tree to minimise any particularly complex conflicts.
>>
>> Actually it needed the fix up below.
>>
>>
>> diff --cc drivers/cpufreq/amd-pstate.c
>> index d96bb3e202ee,66fdc74f13ef..0d4c0de89a00
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@@ -389,10 -389,9 +389,10 @@@ static inline int amd_pstate_cppc_enabl
>> static int msr_init_perf(struct amd_cpudata *cpudata)
>> {
>> union perf_cached perf = READ_ONCE(cpudata->perf);
>> - u64 cap1, numerator;
>> + u64 cap1, numerator, cppc_req;
>> + u8 min_perf;
>>
>> - int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
>> + int ret = rdmsrq_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
>> &cap1);
>> if (ret)
>> return ret;
>> @@@ -401,22 -400,6 +401,22 @@@
>> if (ret)
>> return ret;
>>
>> - ret = rdmsrl_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
>> ++ ret = rdmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
>> + if (ret)
>> + return ret;
>> +
>> + WRITE_ONCE(cpudata->cppc_req_cached, cppc_req);
>> + min_perf = FIELD_GET(AMD_CPPC_MIN_PERF_MASK, cppc_req);
>> +
>> + /*
>> + * Clear out the min_perf part to check if the rest of the MSR is 0, if yes, this is an
>> + * indication that the min_perf value is the one specified through the BIOS option
>> + */
>> + cppc_req &= ~(AMD_CPPC_MIN_PERF_MASK);
>> +
>> + if (!cppc_req)
>> + perf.bios_min_perf = min_perf;
>> +
>> perf.highest_perf = numerator;
>> perf.max_limit_perf = numerator;
>> perf.min_limit_perf = FIELD_GET(AMD_CPPC_LOWEST_PERF_MASK, cap1);
>
> This is now a conflict between the pm tree and Linus' tree.
>
I thought that Ingo added an extra #define for compatibility?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: linux-next: manual merge of the tip tree with the pm tree
2025-05-28 14:14 ` Limonciello, Mario
@ 2025-05-28 22:12 ` Stephen Rothwell
0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2025-05-28 22:12 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Rafael J. Wysocki, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Ugwekar, Dhananjay, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]
Hi Mario,
On Wed, 28 May 2025 14:14:40 +0000 "Limonciello, Mario" <Mario.Limonciello@amd.com> wrote:
>
> On 5/27/25 22:50, Stephen Rothwell wrote:
> >
> > On Mon, 12 May 2025 15:23:26 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 12 May 2025 14:55:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>
> >>> Today's linux-next merge of the tip tree got a conflict in:
> >>>
> >>> drivers/cpufreq/amd-pstate.c
> >>>
> >>> between commit:
> >>>
> >>> 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
> >>>
> >>> from the pm tree and commit:
> >>>
> >>> d7484babd2c4 ("x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'")
> >>>
> >>> from the tip tree.
> >>>
> >>> I fixed it up (the former removed a line updated by the latter) and can
> >>> carry the fix as necessary. This is now fixed as far as linux-next is
> >>> concerned, but any non trivial conflicts should be mentioned to your
> >>> upstream maintainer when your tree is submitted for merging. You may
> >>> also want to consider cooperating with the maintainer of the conflicting
> >>> tree to minimise any particularly complex conflicts.
> >>
> >> Actually it needed the fix up below.
> >>
> >>
> >> diff --cc drivers/cpufreq/amd-pstate.c
> >> index d96bb3e202ee,66fdc74f13ef..0d4c0de89a00
> >> --- a/drivers/cpufreq/amd-pstate.c
> >> +++ b/drivers/cpufreq/amd-pstate.c
> >> @@@ -389,10 -389,9 +389,10 @@@ static inline int amd_pstate_cppc_enabl
> >> static int msr_init_perf(struct amd_cpudata *cpudata)
> >> {
> >> union perf_cached perf = READ_ONCE(cpudata->perf);
> >> - u64 cap1, numerator;
> >> + u64 cap1, numerator, cppc_req;
> >> + u8 min_perf;
> >>
> >> - int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
> >> + int ret = rdmsrq_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
> >> &cap1);
> >> if (ret)
> >> return ret;
> >> @@@ -401,22 -400,6 +401,22 @@@
> >> if (ret)
> >> return ret;
> >>
> >> - ret = rdmsrl_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
> >> ++ ret = rdmsrq_on_cpu(cpudata->cpu, MSR_AMD_CPPC_REQ, &cppc_req);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + WRITE_ONCE(cpudata->cppc_req_cached, cppc_req);
> >> + min_perf = FIELD_GET(AMD_CPPC_MIN_PERF_MASK, cppc_req);
> >> +
> >> + /*
> >> + * Clear out the min_perf part to check if the rest of the MSR is 0, if yes, this is an
> >> + * indication that the min_perf value is the one specified through the BIOS option
> >> + */
> >> + cppc_req &= ~(AMD_CPPC_MIN_PERF_MASK);
> >> +
> >> + if (!cppc_req)
> >> + perf.bios_min_perf = min_perf;
> >> +
> >> perf.highest_perf = numerator;
> >> perf.max_limit_perf = numerator;
> >> perf.min_limit_perf = FIELD_GET(AMD_CPPC_LOWEST_PERF_MASK, cap1);
> >
> > This is now a conflict between the pm tree and Linus' tree.
> >
>
> I thought that Ingo added an extra #define for compatibility?
Having that define does not change the above conflict at all. It just
means that further additions of calls to rdmsrl_safe_on_cpu() will not
cause build failures.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2025-05-28 22:12 UTC | newest]
Thread overview: 65+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-17 3:43 linux-next: manual merge of the tip tree with the pm tree Stephen Rothwell
2025-04-17 11:22 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
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
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-11-25 5:46 Stephen Rothwell
2014-11-25 21:16 ` Rafael J. Wysocki
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).