[Deepin-Kernel-SIG] [linux 6.6-y] [UOS] sync and refactor ec support for phytium platform

[opsiff]

Summary by Sourcery

Add Phytium ARM64 laptop EC support and platform driver integration, including chassis-type helpers and EC-based power, backlight, hotkey, sensor, and event handling.

New Features:

• Expose DMI-based chassis type helpers for identifying laptops and all-in-one systems.
• Introduce a Phytium ARM64 laptop EC platform driver providing backlight, hotkey, lid, gsensor, battery, AC, and power button handling.
• Add EC IT8528 communication, interrupt handling, and sensor (battery temperature, GPU temperature, CPU/GPU fan) support for Phytium platforms.
• Enable ARM64 platform driver hierarchy and Phytium-specific platform drivers in the build.

Bug Fixes:

• Avoid removing ACPI EC handlers on Phytium systems when setup fails, preserving platform-specific EC behavior.

Enhancements:

• Extend CPU type helpers to include Phytium machine detection for conditional platform logic.

[sourcery-ai]

Reviewer's Guide

Adds a Phytium-specific EC / laptop platform driver for ARM64, including EC command helpers, sensor exposure, power and hotkey handling, and integrates new chassis-type helpers plus a Phytium ACPI EC quirk; wires the new platform directory into the ARM64 drivers tree.

File-Level Changes

Change	Details	Files
Introduce generic chassis type helpers and use them for Phytium laptop/all-in-one detection and backlight behavior.	Add DMI-based chassis type lookup with cached numeric value and export helpers to classify laptop and all-in-one systems Expose new chassis helpers via linux/classtypes.h and include needed types/kstrtox headers Use chassis helpers in the Phytium laptop driver to conditionally manage backlight and suspend/resume behavior	lib/classtypes.c include/linux/classtypes.h drivers/platform/arm64/phytium/phyt_laptop.c
Add Phytium EC / laptop platform driver with power, backlight, hotkeys, gsensor, and interrupt handling.	Implement a large Phytium laptop platform driver that talks to an IT8528 EC over LPC/GPIO, registering backlight, input, power_supply and hwmon interfaces Handle EC event interrupts via both LPC and GPIO paths, including SCI event queue cleanup and suspend/resume integration Wire up EC-based hotkeys, gsensor events, power button, lid, WiFi, mic mute, airplane mode, and screen lock handling	drivers/platform/arm64/phytium/phyt_laptop.c drivers/platform/arm64/phytium/ec_it8528.h drivers/platform/arm64/phytium/ec_it8528.c drivers/platform/arm64/phytium/ec_sensor.c
Provide EC access helpers for IT8528 and hook EC sensors via hwmon.	Add IT8528 EC register definitions and helper APIs for indexed read/write and event handling, including enabling/disabling EC SCI interrupts Implement EC transaction logic with proper IBF/OBF polling and locking, plus LPC interrupt helpers targeting Phytium PIO Expose temperature and fan speed readings via hwmon sysfs attributes backed by EC registers	drivers/platform/arm64/phytium/ec_it8528.h drivers/platform/arm64/phytium/ec_it8528.c drivers/platform/arm64/phytium/ec_sensor.c
Wire in Phytium ARM64 platform directory and configuration, and add Phytium machine identifier.	Add arm64 platform Makefile and Kconfig entries plus Phytium-specific platform Makefile wiring under drivers/platform Register new Phytium EC and laptop objects under CONFIG_PHYTIUM_EC and CONFIG_PHYTIUM_LAPTOP Add Phytium machine-type helper macro usage in cputypes to support cpu_is_phytium-style checks	drivers/platform/Makefile drivers/platform/arm64/Makefile drivers/platform/arm64/phytium/Makefile drivers/platform/Kconfig include/linux/cputypes.h arch/arm64/configs/deepin_arm64_desktop_defconfig MAINTAINERS
Add Phytium-specific ACPI EC setup quirk to avoid removing handlers on non-Phytium failures.	Gate ec_remove_handlers() in acpi_ec_setup() behind an ARCH_PHYTIUM check and a runtime implementor check for ARM_CPU_IMP_PHYTIUM	drivers/acpi/ec.c

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from opsiff. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In lib/classtypes.c, get_chassis_types() uses dmi_get_system_info() but the file does not include <linux/dmi.h>, which will break the build on some configs; include the appropriate header explicitly rather than relying on indirect inclusion.
• In ft_lpc_event_probe() the condition if (!read_cpuid_implementor() == ARM_CPU_IMP_PHYTIUM) is almost certainly wrong due to operator precedence (the ! applies before ==); this should be rewritten as an explicit inequality comparison, e.g. if (read_cpuid_implementor() != ARM_CPU_IMP_PHYTIUM) or by using the new cpu_is_phytium() helper.
• In ec_sensor.c, the various *_data buffers are allocated with kzalloc() and never freed; consider using devm_kzalloc() (tied to pdev->dev) or passing NULL as the hwmon data pointer to avoid persistent allocations.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `lib/classtypes.c`, `get_chassis_types()` uses `dmi_get_system_info()` but the file does not include `<linux/dmi.h>`, which will break the build on some configs; include the appropriate header explicitly rather than relying on indirect inclusion.
- In `ft_lpc_event_probe()` the condition `if (!read_cpuid_implementor() == ARM_CPU_IMP_PHYTIUM)` is almost certainly wrong due to operator precedence (the `!` applies before `==`); this should be rewritten as an explicit inequality comparison, e.g. `if (read_cpuid_implementor() != ARM_CPU_IMP_PHYTIUM)` or by using the new `cpu_is_phytium()` helper.
- In `ec_sensor.c`, the various `*_data` buffers are allocated with `kzalloc()` and never freed; consider using `devm_kzalloc()` (tied to `pdev->dev`) or passing `NULL` as the hwmon data pointer to avoid persistent allocations.

## Individual Comments

### Comment 1
<location path="drivers/platform/arm64/phytium/phyt_laptop.c" line_range="1113-1114" />
<code_context>
+	return sprintf(buf, "%d\n", x_val);
+}
+
+static struct kobj_attribute gsensor_attr =
+	__ATTR(value_x, 0644, gsensor_show, NULL);
+
+static struct attribute *gsensor_attrs[] = {
</code_context>
<issue_to_address>
**issue (bug_risk):** Use read-only sysfs permissions or add a store handler

The attribute is exposed as 0644 but has no store callback, so any write attempts will fail with -EIO. Either change the mode to 0444/S_IRUGO if it’s meant to be read-only, or add a store handler if writes are required.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Use read-only sysfs permissions or add a store handler

The attribute is exposed as 0644 but has no store callback, so any write attempts will fail with -EIO. Either change the mode to 0444/S_IRUGO if it’s meant to be read-only, or add a store handler if writes are required.