Skip to content

Added quirk for Surface Go touchscreen#100

Merged
qzed merged 1 commit intolinux-surface:v5.12-surface-develfrom
zoltantamasvajda:surface-go-touchscreen-battery-fix
Jun 3, 2021
Merged

Added quirk for Surface Go touchscreen#100
qzed merged 1 commit intolinux-surface:v5.12-surface-develfrom
zoltantamasvajda:surface-go-touchscreen-battery-fix

Conversation

@zoltantamasvajda
Copy link
Contributor

The Elantech touchscreen/digitizer in the Surface Go mistakenly shows up as having capable of reporting battery (even though it actually cannot). This results in a "low battery" message popping up every time you try to use the pen. This patch adds a quirk allowing the kernel to ignore the the non-existent battery and get rid of the false low battery messages.

Copy link
Member

@qzed qzed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@qzed qzed merged commit b7a5754 into linux-surface:v5.12-surface-devel Jun 3, 2021
@qzed
Copy link
Member

qzed commented Jun 3, 2021

Do you plan on taking this upstream?

@zoltantamasvajda zoltantamasvajda deleted the surface-go-touchscreen-battery-fix branch June 3, 2021 14:04
@zoltantamasvajda
Copy link
Contributor Author

I can try and see if they want it. This is more of a workaround than a real solution though. I think the reason why it reports having a battery is that the device does not get identified properly so it uses the default values for most properties which just so happens to be true for having a battery. Adding it as a quirk is just kicking the can down the road until someone makes a custom driver.

@qzed
Copy link
Member

qzed commented Jun 3, 2021

Given that there isn't any driver like this in the works yet (AFAIK), it's probably a good idea to have that upstream. It can always be removed later on. Also there seem to be at least two other workarounds of this sort (7c38e76, decfe49), so this might be a more or less common issue.

@zoltantamasvajda
Copy link
Contributor Author

Patch submitted upstream. I'll let you know how it goes.

@zoltantamasvajda
Copy link
Contributor Author

Patch applied upstream! 🥳

@qzed
Copy link
Member

qzed commented Jun 14, 2021

Awesome, thanks!

kitakar5525 pushed a commit to kitakar5525/linux-kernel that referenced this pull request Oct 26, 2021
With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we
get:

BUG: scheduling while atomic: swapper/1/0/0x00000000
no locks held by swapper/1/0.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ linux-surface#100
Call Trace:
 dump_stack_lvl+0xac/0x108
 __schedule_bug+0xac/0xe0
 __schedule+0xcf8/0x10d0
 schedule_idle+0x3c/0x70
 do_idle+0x2d8/0x4a0
 cpu_startup_entry+0x38/0x40
 start_secondary+0x2ec/0x3a0
 start_secondary_prolog+0x10/0x14

This is because powerpc's arch_cpu_idle_dead() decrements the idle task's
preempt count, for reasons explained in commit a7c2bb8 ("powerpc:
Re-enable preemption before cpu_die()"), specifically "start_secondary()
expects a preempt_count() of 0."

However, since commit 2c669ef ("powerpc/preempt: Don't touch the idle
task's preempt_count during hotplug") and commit f1a0a37 ("sched/core:
Initialize the idle task with preemption disabled"), that justification no
longer holds.

The idle task isn't supposed to re-enable preemption, so remove the
vestigial preempt_enable() from the CPU offline path.

Tested with pseries and powernv in qemu, and pseries on PowerVM.

Fixes: 2c669ef ("powerpc/preempt: Don't touch the idle task's preempt_count during hotplug")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015173902.2278118-1-nathanl@linux.ibm.com
qzed pushed a commit that referenced this pull request Oct 31, 2021
[ Upstream commit 787252a ]

With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we
get:

BUG: scheduling while atomic: swapper/1/0/0x00000000
no locks held by swapper/1/0.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ #100
Call Trace:
 dump_stack_lvl+0xac/0x108
 __schedule_bug+0xac/0xe0
 __schedule+0xcf8/0x10d0
 schedule_idle+0x3c/0x70
 do_idle+0x2d8/0x4a0
 cpu_startup_entry+0x38/0x40
 start_secondary+0x2ec/0x3a0
 start_secondary_prolog+0x10/0x14

This is because powerpc's arch_cpu_idle_dead() decrements the idle task's
preempt count, for reasons explained in commit a7c2bb8 ("powerpc:
Re-enable preemption before cpu_die()"), specifically "start_secondary()
expects a preempt_count() of 0."

However, since commit 2c669ef ("powerpc/preempt: Don't touch the idle
task's preempt_count during hotplug") and commit f1a0a37 ("sched/core:
Initialize the idle task with preemption disabled"), that justification no
longer holds.

The idle task isn't supposed to re-enable preemption, so remove the
vestigial preempt_enable() from the CPU offline path.

Tested with pseries and powernv in qemu, and pseries on PowerVM.

Fixes: 2c669ef ("powerpc/preempt: Don't touch the idle task's preempt_count during hotplug")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015173902.2278118-1-nathanl@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants