Hi All, I've 2 different kernel bugs where the fix requires differentiating between Cherry Trail vs Brasswell, just checking the CPU model does not allow to differentiate between these 2 since they are both using Airmont cores. I have the same issue with the Bay Trail laptop SoCs vs the Bay Trail-T tablet SoCs, but for now lets focus on Cherry Trail vs Brasswell since that is less confusing: https://ark.intel.com/content/www/us/en/ark/products/codename/46629/cherry-trail.html https://ark.intel.com/content/www/us/en/ark/products/codename/66094/braswell.html So I see a number of possible solutions here: 1) Do a (substring) check on the CPU model-name checking for "x5-Z8" and "x7-Z8" 2) Check for presence of some embedded peripheral which is present on one but not the other. E.g. The Braswell devices have HDA audio where as the Cherry Trail devices use the "Low Power Engine (LPE) Audio Controller" 3) Check for acpi_gbl_reduced_hardware, but I'm not sure if that is a reliable indicator of running on the tablet versions of the SoCs. 1 and 2 will work but neither is very pretty, I guess I could try to spend some more time investigating 3. But I only have limited access to the non tablet versions of the Bay Trail and I'm not sure if I have any Braswell devices at all. So I was wondering if anyone else has any better ideas here? Regards, Hans p.s. Just FYI the 2 issues which I want to resolve are: 1. Prevent drivers/platform/x86/intel_int0002_vgpio.c binding on Braswell (non "tablet") SoCs. The INT0002 ACPI device is used for some wakeup events (from S2idle) on the tablet (Cherry Trail) versions of the SoC. The current code will also bind to the INT0002 ACPI device (if present) on Braswell, this is causing suspend/resume issues on some devices. ATM we are working around this by setting the IRQCHIP_SKIP_SET_WAKE on the irq-chip for the INT0002 vGPIO pin. But this in turn is breaking wakeup by USB peripherals on Cherry Trail devices. If we can just stop the driver from binding on Braswell devices all together then that would be better. 2. Deal with non functional /sys/class/backlight/acpi_video[0-7] devices showing up on BYT/CHT based media-boxes / hdmi-sticks. These devices do not have a LCD panel, so there will be no "native" backlight driver causing drivers/acpi/video-detect.c to select acpi_backlight_video as backlight-type. drivers/acpi/acpi-video.c tries to avoid registering non-functional /sys/class/backlight/acpi_video devices in cases like this, but that depends on a DMI chassis-type check (to avoid suppressing the backlight interface on laptops where we likely do want it) and many of these media-boxes / hdmi-sticks are derived from BYT/CHT tablet designs and often the DMI chassis type still says "Tablet". Actual Cherry Trail devices with a LCD panel always use the native intel_backlight interface, but I guess some Braswell based devices might use the acpi_video interface. I would like to be able to add some code the the ACPI video code which simply ignores the broken acpi_video interface on Cherry Trail devices, while still using its normal detection logic on Brasswell devices. The alternative would be an ever growing list of DMI based quirks which is undesirable.
