mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Robinson <alex@ironrobin.net>
To: "Hans de Goede" <hansg@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Steev Klimaszewski <threeway@gmail.com>,
	platform-driver-x86@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/3] Lenovo ThinkPad X13s embedded controller support
Date: Fri, 02 Oct 2026 15:42:48 +0000	[thread overview]
Message-ID: <20261002154231.31376-1-alex@ironrobin.net> (raw)

Add Device Tree support for the ThinkPad X13s embedded controller,
providing keyboard-backlight control and firmware-driven brightness
notifications. Its event, backlight and power-management interfaces
differ from the T14s EC and require a separate driver.

EC wakeup remains disabled by default because lid closure can trigger
an unwanted wakeup and no selective event mask is known. Other EC event
mappings remain outside the scope of this series.

This follows earlier X13s EC work by Konrad Dybcio and Steev Klimaszewski.
Development was assisted by an LLM, including analysis of the X13s ACPI
DSDT and review of the implementation.

Changes in v5:
- Replace the private suspended/access-blocked flag and deferred-event
  handling with IRQ quiescing and LED class suspend/resume helpers.
- Flush pending LED brightness restoration before re-enabling the EC
  event IRQ, so pending lid events are handled afterwards.
- Preserve the EC lid-restore brightness during PM blanking/restoration.
- Update the LED brightness cache on lid-open restoration without a
  hardware-change notification, avoiding a spurious backlight OSD.
  Retain notifications for firmware-driven changes such as Fn+Space.
- Include dev_printk.h directly for device logging helpers.
- Leave the binding and DTS unchanged from v4.

Changes in v4:
- Set GPIO103 bias-pull-up explicitly, based on its firmware-inherited
  configuration measured at pinctrl probe before Linux claimed or
  configured the pin. CTL offset 0x67000 read 0x00000003 (pull field 3).
  The temporary measurement instrumentation is not included.
- Remove output-high from the GPIO176 pinctrl state. The driver already
  requests GPIOD_OUT_HIGH at probe and controls the line during sleep.
- Restore the suspend brightness snapshot only if it was successfully
  captured during that suspend, avoiding restoration of a stale value.
- Use FIELD_MODIFY(), validate brightness against the LED maximum, and
  simplify transfer error handling and selected mutex-protected paths.
- Include linux/ratelimit.h explicitly and adjust conditional formatting.
- Shorten commit messages to focus on rationale rather than the diff.

Changes in v3:
- Disable EC wakeup by default without disabling runtime IRQ handling.
- Retain wakeup-source as a description of hardware capability.
- Remove the Kconfig help text's claim of wake support.

Changes in v2:
- Make backlight snapshots and EC power-management operations best-effort.
- Save firmware- and software-selected brightness in the EC and restore
  the EC-saved brightness on lid open.
- Process deferred events after the normal resume brightness restore.
- Add QUP8 pin configuration verified on hardware and fix DT node ordering.

Testing:
- Confirmed GPIO103's firmware-inherited pull-up on a ThinkPad X13s using
  a vanilla kernel with temporary probe-time instrumentation.
- Verified that all three v5 patches apply in order to Linux v7.3-rc4
  without the separate PCI workaround and reproduce the current EC
  source files byte-for-byte.
- Earlier v2 hardware testing covered keyboard-backlight control,
  firmware brightness changes, s2idle, lid-close/open brightness
  restoration, and EC wake events. Those results are historical and do
  not establish validation of the complete v5 series or its revised PM
  handling. No v5 build or runtime validation was performed while
  preparing this submission directory.

Earlier series:
https://lore.kernel.org/all/20260925215358.33417-1-alex@ironrobin.net/

Alex Robinson (3):
  dt-bindings: embedded-controller: Add Lenovo ThinkPad X13s EC
  platform: arm64: Add Lenovo ThinkPad X13s EC driver
  arm64: dts: qcom: sc8280xp-x13s: Add embedded controller

base-commit: 93f51579e7df248780214094418f205253383cc5


             reply	other threads:[~2026-10-02 15:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 15:42 Alex Robinson [this message]
2026-10-02 15:42 ` [PATCH v5 1/3] dt-bindings: embedded-controller: Add Lenovo ThinkPad X13s EC Alex Robinson
2026-10-02 15:43 ` [PATCH v5 2/3] platform: arm64: Add Lenovo ThinkPad X13s EC driver Alex Robinson
2026-10-02 15:43 ` [PATCH v5 3/3] arm64: dts: qcom: sc8280xp-x13s: Add embedded controller Alex Robinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261002154231.31376-1-alex@ironrobin.net \
    --to=alex@ironrobin.net \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=threeway@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®