Conversation
…/git/vfs/vfs.git # Conflicts: # fs/smb/server/smb2pdu.c # fs/smb/server/vfs.c # fs/smb/server/vfs.h
…he.git # Conflicts: # drivers/gpu/drm/amd/amdkfd/kfd_migrate.c # net/ceph/osd_client.c
…bitmask" This reverts commit ca46a07 due to. /tmp/next/build/lib/vdso/gettimeofday.c: In function '__cvdso_clock_gettime_common': /tmp/next/build/lib/vdso/gettimeofday.c:288:31: error: implicit declaration of function 'BITS_PER_TYPE'; did you mean 'BITS_PER_LONG'? [-Wimplicit-function-declaration] 288 | BUILD_BUG_ON(clock >= BITS_PER_TYPE(msk)); | ^~~~~~~~~~~~~ /tmp/next/build/include/linux/compiler_types.h:682:23: note: in definition of macro '__compiletime_assert' 682 | if (!(condition)) \ | ^~~~~~~~~ /tmp/next/build/include/linux/compiler_types.h:702:9: note: in expansion of macro '_compiletime_assert' 702 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ /tmp/next/build/include/linux/build_bug.h:40:37: note: in expansion of macro 'compiletime_assert' 40 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ /tmp/next/build/include/linux/build_bug.h:51:9: note: in expansion of macro 'BUILD_BUG_ON_MSG' 51 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~~~~~~~~~~~~~ /tmp/next/build/lib/vdso/gettimeofday.c:288:9: note: in expansion of macro 'BUILD_BUG_ON' 288 | BUILD_BUG_ON(clock >= BITS_PER_TYPE(msk)); | ^~~~~~~~~~~~ Signed-off-by: Mark Brown <broonie@kernel.org>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe DMI table now matches AYANEO 2 by exact board name and adds an exact AYANEO 2S match assigned the charge-limit quirk. ChangesAYANEO DMI matching
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to AYANEO 2S gains charge control while retaining fan control. No material merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Git: CodeRabbit could not clone the repository, so clone-backed analysis was skipped and this review may be incomplete. Verify repository clone access, such as SSH credentials, before requesting another full review. If clone access is intentionally unavailable, use Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: Mark Brown <broonie@kernel.org>
[Why] Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564) works perfectly with VRR after testing. VRR and FreeSync compatibility is explicitly advertised as a feature so it's addition is a formality. Support FreeSync info packet passthrough and "generic" HDMI VRR. [How] Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed() Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> (cherry picked from commit 7b2436287ed953496ad1c9eb5820f00b75db597f) (cherry picked from commit a9c7548) (cherry picked from commit 63b562c) (cherry picked from commit e20d460) (cherry picked from commit 39c6e1f)
The detachable keyboard shipped with the ROG Zephyrus Duo GX651AR (0b05:1ce6) is a ROG N-Key keyboard, but it is not listed in asus_devices[], so its interfaces are left to hid-generic and its vendor usages are never mapped by asus_input_mapping(). Add it with QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD, matching the other ROG N-Key keyboards. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 8d70b5f) (cherry picked from commit 9582bd4) (cherry picked from commit 29ee8b6) (cherry picked from commit 9bd6541)
… interfaces On the ROG Zephyrus Duo GX651AR (0b05:1ce6) the hotkeys live on report 0x5a on an interface whose descriptor holds nothing but two ASUS vendor collections. Neither satisfies IS_INPUT_APPLICATION(), so hidinput_connect() creates no input device, asus_input_mapping() never runs and every hotkey is dropped by asus_event() as unmapped. Set HID_QUIRK_HIDINPUT_FORCE on ROG N-Key interfaces that carry an ASUS vendor input report so those usages get mapped. Interfaces left with no mapped usage are still discarded by hidinput_has_been_populated(). The vendor check reads report_enum[HID_INPUT_REPORT], so interfaces with no input reports, such as the RGB control interface, are unaffected. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 69887e3) (cherry picked from commit 4e70783) (cherry picked from commit b3ceeae) (cherry picked from commit c492209)
…Bluetooth The GX651AR keyboard enumerates as 0b05:1ce6 over USB but pairs as 0b05:1ce7 in Bluetooth mode, where the keyboard, consumer and both ASUS vendor collections (reports 0x5a and 0x5d) sit on a single HID device. Add it with the same quirks as the USB entry. Bind to HID_GROUP_GENERIC so that hid-multitouch keeps the digitizer. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit b0dbc09) (cherry picked from commit f460429) (cherry picked from commit af0d892) (cherry picked from commit 98993b7)
…X651AR Fn+F12 on the GX651AR keyboard emits ASUS vendor code 0x9c, which asus_input_mapping() does not know about, so asus_event() drops it as unmapped. Map it to KEY_F19. F13 to F18 are already used for ASUS toggles that have no generic keycode. Tested-by: Cymirk <cymirk@icloud.com> Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> (cherry picked from commit 337a811) (cherry picked from commit a980051) (cherry picked from commit aafe6db) (cherry picked from commit 6bc535e)
…=7 and dump serial log head on banner failure
The smoke test greps the captured serial console log for the kernel
banner ("Linux version <KREL> "), but the banner is printed at
KERN_NOTICE while some distro configs default the console to a quieter
level: Arch ships CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4, which suppresses
notice (and info) messages entirely. The result was a confusing failure
mode: the kernel booted to userspace just fine (BOOT_OK marker, printed
by init directly on /dev/ttyS0), yet the banner check failed because
the console log only carried a few high-priority lines.
Pin loglevel=7 on the test kernel command line so every distro kernel
logs verbosely enough for the banner to be captured, and replace the
useless "^Linux version" grep in the failure path (banner lines are
prefixed with a "[ 0.000000] " timestamp, so that grep could never
match) with a dump of the first serial console lines.
Verified locally against a kernel built with the exact Arch config
pipeline: the run failed identically to CI before the change and passes
both the bios-pc and uefi-q35 legs after it.
(cherry picked from commit af2b902)
(cherry picked from commit 98d39d0)
(cherry picked from commit adfb8ee)
github-actions
Bot
force-pushed
the
master
branch
from
October 1, 2026 08:30
adfb8ee to
cf99356
Compare
The AYANEO 2S reports "AYANEO 2S" in DMI_BOARD_NAME. The existing "AYANEO 2" entry uses DMI_MATCH, a substring match, so it also matches the 2S. That entry selects quirk_fan, so the board gets fan control but charge control is never registered: probe() skips the battery hook and no charge_behaviour attribute appears on the battery. The failure is silent: no error path is involved, only a false condition, so nothing is logged. The only symptom is the missing sysfs attribute. The EC charge register works on this board. Tested on an AYANEO 2S (BIOS 2.15_S20, 7840U) by adding the entry below and using the resulting attribute: # echo inhibit-charge > /sys/class/power_supply/BAT0/charge_behaviour (~20s later) # cat /sys/class/power_supply/BAT0/power_now ; cat .../status 0 Not charging # echo auto > /sys/class/power_supply/BAT0/charge_behaviour (~20s later) 22903000 Charging The EC does not act on the write immediately. In testing it took anywhere from a few seconds to about a minute. Narrow the "AYANEO 2" entry to DMI_EXACT_MATCH and add an entry for "AYANEO 2S" selecting quirk_charge_limit, which enables fan control as well. "AYANEO 2" and "AYANEO 2S" are the only board names in that family, so the exact match does not drop fan control from any other board. The out-of-tree ShadowBlip ayaneo-platform driver made the same distinction: it matched "AYANEO 2S" with DMI_EXACT_MATCH as a model of its own, separate from "AYANEO 2", and listed only the 2S in its bypass-charge switch. Assisted-by: LLM Signed-off-by: Tiago Silva <tiago.paulo@live.com>
TiPSilva
force-pushed
the
ayaneo-ec/2s-charge-control
branch
from
October 1, 2026 12:22
9e58193 to
ced900c
Compare
github-actions
Bot
force-pushed
the
master
branch
2 times, most recently
from
October 3, 2026 07:48
f3282c8 to
a9cf7c7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "AYANEO 2" entry uses DMI_MATCH, which is a substring match, so it also catches the AYANEO 2S and hands it quirk_fan. Charge control is never registered on the 2S: probe() skips the battery hook and no charge_behaviour attribute shows up. It fails silently, it is a false condition, not an error path, so nothing is logged.
This narrows the "AYANEO 2" entry to DMI_EXACT_MATCH and adds "AYANEO 2S" with quirk_charge_limit, which carries has_fan_control as well, so the 2S keeps fan control.
Tested on an AYANEO 2S (BIOS 2.15_S20, 7840U):
inhibit-chargetakes power_now to 0 and status to "Not charging", 'auto' brings it back to ~22.9 W and "Charging". The EC does not act on the write immediately; in testing it took anywhere from a few seconds to about a minute.Measurements and the full rationale are in the commit message.
An LLM (Claude) assisted with the investigation and the changelog. I reviewed the change and tested it on my own AYANEO 2S.
Summary by CodeRabbit