x86/cpu: Introduce INTEL_CPU_FAM*_NODATA() helper macros

PATCH In review Andy Shevchenko 4 participants 7 messages Jan 9, 2019 – Jan 14, 2019

Subsystems (3)

x86 ACPI Intel CPU family model numbers

lore

Share & tools

lore

Andy Shevchenko

author

2019-01-09 16:57 UTC #0 lore raw

PATCH v2 1/3 x86/cpu: Introduce INTEL_CPU_FAM*_NODATA() helper macros

These macros are often used by the drivers and we have already a lot of duplication as ICPU() macro across them.

Provide a generic x86 macro for users.

This adds no driver data variants.

Signed-off-by Andy Shevchenko <[email protected]>

---
 arch/x86/include/asm/intel-family.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/x86/include/asm/intel-family.h +8 -2

index 25b28760fada..afd70055a750 100644
@@ -86,10 +86,16 @@
 	.family		= _family,				\
 	.model		= _model,				\
 	.feature	= X86_FEATURE_ANY,			\
-	.driver_data	= (kernel_ulong_t)&_driver_data		\
+	.driver_data	= (kernel_ulong_t)_driver_data		\
 }
 
 #define INTEL_CPU_FAM6(_model, _driver_data)			\
-	INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data)
+	INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, &_driver_data)
+
+#define INTEL_CPU_FAM_ANY_NODATA(_family, _model)		\
+	INTEL_CPU_FAM_ANY(_family, _model, 0)
+
+#define INTEL_CPU_FAM6_NODATA(_model)				\
+	INTEL_CPU_FAM_ANY_NODATA(6, INTEL_FAM6_##_model)
 
 #endif /* _ASM_X86_INTEL_FAMILY_H */

Signature · 1 line

2.20.1

Andy Shevchenko

author

2019-01-09 16:57 UTC #1 lore raw

PATCH v2 2/3 ACPI / LPSS: Get rid of custom ICPU() macro

Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.

No functional change intended.

Signed-off-by Andy Shevchenko <[email protected]>

Acked-by Rafael J. Wysocki <[email protected]>

---
 drivers/acpi/acpi_lpss.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/acpi/acpi_lpss.c +2 -4

index 5f94c35d165f..633a528bb6ea 100644
@@ -311,11 +311,9 @@ static const struct lpss_device_desc bsw_spi_dev_desc = {
 	.setup = lpss_deassert_reset,
 };
 
-#define ICPU(model)	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
-
 static const struct x86_cpu_id lpss_cpu_ids[] = {
-	ICPU(INTEL_FAM6_ATOM_SILVERMONT),	/* Valleyview, Bay Trail */
-	ICPU(INTEL_FAM6_ATOM_AIRMONT),	/* Braswell, Cherry Trail */
+	INTEL_CPU_FAM6_NODATA(ATOM_SILVERMONT),	/* Valleyview, Bay Trail */
+	INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT),	/* Braswell, Cherry Trail */
 	{}
 };

Signature · 1 line

2.20.1

Borislav Petkov

maintainer

2019-01-14 11:08 UTC #2 lore raw

Re: [PATCH v2 2/3] ACPI / LPSS: Get rid of custom ICPU() macro

Quoted 15 lines · Andy Shevchenko

Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.
No functional change intended.
Signed-off-by Andy Shevchenko <[email protected]>
Acked-by Rafael J. Wysocki <[email protected]>
---
 drivers/acpi/acpi_lpss.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/acpi/acpi_lpss.c +0 -0
index 5f94c35d165f..633a528bb6ea 100644

drivers/acpi/acpi_lpss.c static const struct lpss_device_desc bsw_spi_dev_desc = { · line 317

Quoted 7 lines

drivers/acpi/acpi_lpss.c +0 -3

@@ -311,11 +311,9 @@ static const struct lpss_device_desc bsw_spi_dev_desc = {
 	.setup = lpss_deassert_reset,
 };
 
-#define ICPU(model)	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
-
 static const struct x86_cpu_id lpss_cpu_ids[] = {
-	ICPU(INTEL_FAM6_ATOM_SILVERMONT),	/* Valleyview, Bay Trail */

Sorry but the previous one was better: INTEL_FAM6_ATOM_SILVERMONT I can find in the tree...

drivers/acpi/acpi_lpss.c static const struct lpss_device_desc bsw_spi_dev_desc = { · line 315

Quoted 2 lines

drivers/acpi/acpi_lpss.c +1 -1

-	ICPU(INTEL_FAM6_ATOM_AIRMONT),	/* Braswell, Cherry Trail */
+	INTEL_CPU_FAM6_NODATA(ATOM_SILVERMONT),	/* Valleyview, Bay Trail */

For ATOM_SILVERMONT I find different things:

INTEL_CPU_FAM6(ATOM_SILVERMONT
X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT
ICPU(INTEL_FAM6_ATOM_SILVERMONT
...

so you guys need to sit down and agree on a single form of usage and stick with it.

And I'd advise against the first one which cuts off the INTEL_FAM6_ATOM_SILVERMONT and other defines.

Thx.

Signature · 4 lines

Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Andy Shevchenko

author

2019-01-09 16:57 UTC #3 lore raw

PATCH v2 3/3 ACPI / x86: utils: Get rid of custom ICPU() macro

In reply to Andy Shevchenko

Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.

No functional change intended.

Signed-off-by Andy Shevchenko <[email protected]>

Acked-by Rafael J. Wysocki <[email protected]>

---
 drivers/acpi/x86/utils.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

drivers/acpi/x86/utils.c +8 ~~-10~~

index 9a8e286dd86f..408131bcc1fa 100644
@@ -40,8 +40,6 @@ struct always_present_id {
 	const char *uid;
 };
 
-#define ICPU(model)	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
-
 #define ENTRY(hid, uid, cpu_models, dmi...) {				\
 	{ { hid, }, {} },						\
 	{ cpu_models, {} },						\

@@ -54,24 +52,24 @@ static const struct always_present_id always_present_ids[] = {
 	 * Bay / Cherry Trail PWM directly poked by GPU driver in win10,
 	 * but Linux uses a separate PWM driver, harmless if not used.
 	 */
-	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT), {}),
-	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
+	ENTRY("80860F09", "1", INTEL_CPU_FAM6_NODATA(ATOM_SILVERMONT), {}),
+	ENTRY("80862288", "1", INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT), {}),
 	/*
 	 * The INT0002 device is necessary to clear wakeup interrupt sources
 	 * on Cherry Trail devices, without it we get nobody cared IRQ msgs.
 	 */
-	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
+	ENTRY("INT0002", "1", INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT), {}),
 	/*
 	 * On the Dell Venue 11 Pro 7130 and 7139, the DSDT hides
 	 * the touchscreen ACPI device until a certain time
 	 * after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed
 	 * *and* _STA has been called at least 3 times since.
 	 */
-	ENTRY("SYNA7500", "1", ICPU(INTEL_FAM6_HASWELL_ULT), {
+	ENTRY("SYNA7500", "1", INTEL_CPU_FAM6_NODATA(HASWELL_ULT), {
 		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
 	      }),
-	ENTRY("SYNA7500", "1", ICPU(INTEL_FAM6_HASWELL_ULT), {
+	ENTRY("SYNA7500", "1", INTEL_CPU_FAM6_NODATA(HASWELL_ULT), {
 		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7139"),
 	      }),

@@ -87,19 +85,19 @@ static const struct always_present_id always_present_ids[] = {
 	 * was copy-pasted from the GPD win, so it has a disabled KIOX000A
 	 * node which we should not enable, thus we also check the BIOS date.
 	 */
-	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
+	ENTRY("KIOX000A", "1", INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT), {
 		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
 		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
 		DMI_MATCH(DMI_BIOS_DATE, "02/21/2017")
 	      }),
-	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
+	ENTRY("KIOX000A", "1", INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT), {
 		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
 		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
 		DMI_MATCH(DMI_BIOS_DATE, "03/20/2017")
 	      }),
-	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
+	ENTRY("KIOX000A", "1", INTEL_CPU_FAM6_NODATA(ATOM_AIRMONT), {
 		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
 		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),

Signature · 1 line

2.20.1

Rafael J. Wysocki

maintainer

2019-01-11 10:35 UTC #4 lore raw

In reply to Andy Shevchenko

Quoted 9 lines · Andy Shevchenko

These macros are often used by the drivers and we have already a lot of duplication as ICPU() macro across them.
Provide a generic x86 macro for users.
This adds no driver data variants.
Signed-off-by Andy Shevchenko <[email protected]>

If you want me to apply the series, I need an ACK for this one.

Alternatively, if you want to apply it yourself, please feel free to add ACKs from me to the ACPI-related patches in it.

Quoted 30 lines

---
 arch/x86/include/asm/intel-family.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/x86/include/asm/intel-family.h +8 -3

index 25b28760fada..afd70055a750 100644
@@ -86,10 +86,16 @@
        .family         = _family,                              \
        .model          = _model,                               \
        .feature        = X86_FEATURE_ANY,                      \
-       .driver_data    = (kernel_ulong_t)&_driver_data         \
+       .driver_data    = (kernel_ulong_t)_driver_data          \
 }
 
 #define INTEL_CPU_FAM6(_model, _driver_data)                   \
-       INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data)
+       INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, &_driver_data)
+
+#define INTEL_CPU_FAM_ANY_NODATA(_family, _model)              \
+       INTEL_CPU_FAM_ANY(_family, _model, 0)
+
+#define INTEL_CPU_FAM6_NODATA(_model)                          \
+       INTEL_CPU_FAM_ANY_NODATA(6, INTEL_FAM6_##_model)
 
 #endif /* _ASM_X86_INTEL_FAMILY_H */
--

2.20.1

Andy Shevchenko

2019-01-11 13:29 UTC #5 lore raw

Quoted 7 lines · Rafael J. Wysocki

Quoted 4 lines · Andy Shevchenko
These macros are often used by the drivers and we have already a lot of duplication as ICPU() macro across them.

Quoted 8 lines

Quoted 5 lines
Provide a generic x86 macro for users.
This adds no driver data variants.
Signed-off-by Andy Shevchenko <[email protected]>
If you want me to apply the series, I need an ACK for this one.

I hope Ingo can help with this.

Quoted 2 lines

Alternatively, if you want to apply it yourself, please feel free to add ACKs from me to the ACPI-related patches in it.

Thanks, you already gave yours at time of v1.

Quoted 31 lines

---
 arch/x86/include/asm/intel-family.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/x86/include/asm/intel-family.h +8 -3

index 25b28760fada..afd70055a750 100644
@@ -86,10 +86,16 @@
        .family         = _family,                              \
        .model          = _model,                               \
        .feature        = X86_FEATURE_ANY,                      \
-       .driver_data    = (kernel_ulong_t)&_driver_data         \
+       .driver_data    = (kernel_ulong_t)_driver_data          \
 }
 
 #define INTEL_CPU_FAM6(_model, _driver_data)                   \
-       INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data)
+       INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, &_driver_data)
+
+#define INTEL_CPU_FAM_ANY_NODATA(_family, _model)              \
+       INTEL_CPU_FAM_ANY(_family, _model, 0)
+
+#define INTEL_CPU_FAM6_NODATA(_model)                          \
+       INTEL_CPU_FAM_ANY_NODATA(6, INTEL_FAM6_##_model)
 
 #endif /* _ASM_X86_INTEL_FAMILY_H */
--

2.20.1

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Borislav Petkov

maintainer

2019-01-14 11:08 UTC #6 lore raw

In reply to Andy Shevchenko

Quoted 19 lines · Andy Shevchenko

These macros are often used by the drivers and we have already a lot of duplication as ICPU() macro across them.
Provide a generic x86 macro for users.
This adds no driver data variants.
Signed-off-by Andy Shevchenko <[email protected]>
---
 arch/x86/include/asm/intel-family.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
arch/x86/include/asm/intel-family.h +0 -0
index 25b28760fada..afd70055a750 100644
@@ -86,10 +86,16 @@
 	.family		= _family,				\
 	.model		= _model,				\

arch/x86/include/asm/intel-family.h line 95

Quoted 10 lines

arch/x86/include/asm/intel-family.h +4 -2

 	.feature	= X86_FEATURE_ANY,			\
-	.driver_data	= (kernel_ulong_t)&_driver_data		\
+	.driver_data	= (kernel_ulong_t)_driver_data		\
 }
 
 #define INTEL_CPU_FAM6(_model, _driver_data)			\
-	INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, _driver_data)
+	INTEL_CPU_FAM_ANY(6, INTEL_FAM6_##_model, &_driver_data)
+
+#define INTEL_CPU_FAM_ANY_NODATA(_family, _model)		\

"ANY_NODATA" is confusing IMO, as I have no clue what that means. ICPU() and the full model define was fine.

Signature · 4 lines

Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.