<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/acpi/ec.c, branch v4.14.286</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-07-20T14:17:33+00:00</updated>
<entry>
<title>ACPI: EC: Make more Asus laptops use ECDT _GPE</title>
<updated>2021-07-20T14:17:33+00:00</updated>
<author>
<name>Chris Chiu</name>
<email>chris.chiu@canonical.com</email>
</author>
<published>2021-05-20T03:09:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3a8aff135045d3631f5afba6a26dbcaadfad4c90'/>
<id>urn:sha1:3a8aff135045d3631f5afba6a26dbcaadfad4c90</id>
<content type='text'>
[ Upstream commit 6306f0431914beaf220634ad36c08234006571d5 ]

More ASUS laptops have the _GPE define in the DSDT table with a
different value than the _GPE number in the ECDT.

This is causing media keys not working on ASUS X505BA/BP, X542BA/BP

Add model info to the quirks list.

Signed-off-by: Chris Chiu &lt;chris.chiu@canonical.com&gt;
Signed-off-by: Jian-Hong Pan &lt;jhp@endlessos.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: EC: Reference count query handlers under lock</title>
<updated>2020-10-01T11:12:31+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2019-12-27T10:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a43d6b3cbd947c8e7aec84bc5c61fee4b286d89d'/>
<id>urn:sha1:a43d6b3cbd947c8e7aec84bc5c61fee4b286d89d</id>
<content type='text'>
[ Upstream commit 3df663a147fe077a6ee8444ec626738946e65547 ]

There is a race condition in acpi_ec_get_query_handler()
theoretically allowing query handlers to go away before refernce
counting them.

In order to avoid it, call kref_get() on query handlers under
ec-&gt;mutex.

Also simplify the code a bit while at it.

Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk"</title>
<updated>2019-04-20T07:15:06+00:00</updated>
<author>
<name>Zhang Rui</name>
<email>rui.zhang@intel.com</email>
</author>
<published>2019-02-01T06:13:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e3adeb25d440147ae00eefbe9d62cff56dcc7c6'/>
<id>urn:sha1:3e3adeb25d440147ae00eefbe9d62cff56dcc7c6</id>
<content type='text'>
[ Upstream commit b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ]

On some Samsung hardware, it is necessary to clear events accumulated by
the EC during sleep. These ECs stop reporting GPEs until they are manually
polled, if too many events are accumulated.
Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands
unconditionally after resume to clear all the EC query events on those
platforms.

Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk")
removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ
polling logic should handle this case.

Now it has been proved that the EC IRQ Polling logic does not fix the
issue actually because we got regression report on these Samsung
platforms after removing the quirk.

Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME
quirk") to introduce back the Samsung quirk in this patch.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Tested-by: Ortwin Glück &lt;odi@odi.ch&gt;
Tested-by: Francisco Cribari &lt;cribari@gmail.com&gt;
Tested-by: Balazs Varga &lt;balazs4web@gmail.com&gt;
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems</title>
<updated>2018-08-24T11:09:20+00:00</updated>
<author>
<name>Robin H. Johnson</name>
<email>robbat2@gentoo.org</email>
</author>
<published>2018-07-13T20:50:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=119970f4775ba44e46545df5c3237ee8721dc1de'/>
<id>urn:sha1:119970f4775ba44e46545df5c3237ee8721dc1de</id>
<content type='text'>
[ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]

The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.

Signed-off-by: Robin H. Johnson &lt;robbat2@gentoo.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI / EC: Use ec_no_wakeup on Thinkpad X1 Carbon 6th</title>
<updated>2018-08-24T11:08:57+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-06-18T11:17:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dcf6f268deee44671fa9b320b1ba5e9648a5277c'/>
<id>urn:sha1:dcf6f268deee44671fa9b320b1ba5e9648a5277c</id>
<content type='text'>
[ Upstream commit 8195a655e5ce09550aff81b2573d9b015d520cb9 ]

On this system EC interrupt triggers constantly kicking devices out of
low power states and thus blocking power management. The system also has
a PCIe root port hosting Alpine Ridge Thunderbolt controller and it
never gets a chance to go to D3cold because of this.

Since the power button works the same regardless if EC interrupt is
enabled or not during s2idle, add a quirk for this machine that sets
ec_no_wakeup=true preventing spurious wakeups.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI / EC: Restore polling during noirq suspend/resume phases</title>
<updated>2018-04-26T09:02:19+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2018-02-09T21:55:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=afa0ce071488154e28d60b510dd0a3c3d86f7992'/>
<id>urn:sha1:afa0ce071488154e28d60b510dd0a3c3d86f7992</id>
<content type='text'>
[ Upstream commit 3cd091a773936c54344a519f7ee1379ccb620bee ]

Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a
regression) modified the ACPI EC driver so that it doesn't switch
over to busy polling mode during noirq stages of system suspend and
resume in an attempt to fix an issue resulting from that behavior.

However, that modification introduced a system resume regression on
Thinkpad X240, so make the EC driver switch over to the polling mode
during noirq stages of system suspend and resume again, which
effectively reverts the problematic commit.

Fixes: 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197863
Reported-by: Markus Demleitner &lt;m@tfiu.de&gt;
Tested-by: Markus Demleitner &lt;m@tfiu.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: EC: Fix debugfs_create_*() usage</title>
<updated>2018-04-12T10:32:15+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2018-01-02T15:26:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74f5124bc3ff2f6c7fa4386901970766faed5dea'/>
<id>urn:sha1:74f5124bc3ff2f6c7fa4386901970766faed5dea</id>
<content type='text'>
[ Upstream commit 3522f867c13b63cf62acdf1b8ca5664c549a716a ]

acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose
the wrong half on big-endian 64-bit systems.  Fix this by changing its
type to "u32" and removing the cast, as all other code already uses u32
or sometimes even only u8.

Fixes: 1195a098168fcacf (ACPI: Provide /sys/kernel/debug/ec/...)
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI / EC: Fix regression related to PM ops support in ECDT device</title>
<updated>2017-12-05T10:26:33+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2017-09-26T08:54:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=450d75882552d59bb03b1ccb0999e98f5b227532'/>
<id>urn:sha1:450d75882552d59bb03b1ccb0999e98f5b227532</id>
<content type='text'>
commit a64a62ce9a380213dc9e192f762266d70c9b40ec upstream.

On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
ACPI device. Thus the following commit actually removed post-resume
acpi_ec_enable_event() invocation for such platforms, and triggered a
regression on them that after being resumed, EC (actually should be ECDT)
driver stops handling EC events:

 Commit: c2b46d679b30c5c0d7eb47a21085943242bdd8dc
 Subject: ACPI / EC: Add PM operations to improve event handling for resume process

Notice that the root cause actually is "ECDT is not an ACPI device" rather
than "the timing of acpi_ec_enable_event() invocation", this patch fixes
this issue by enumerating ECDT EC as an ACPI device. Due to the existence
of the noirq stage, the ability of tuning the timing of
acpi_ec_enable_event() invocation is still meaningful.

This patch is a little bit different from the posted fix by moving
acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
sure that EC event handling won't be stopped as long as the ACPI EC driver
is bound. Thus the following sequence shouldn't disable EC event handling:
unbind,suspend,resume,bind.

Fixes: c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847
Reported-by: Luya Tshimbalanga &lt;luya@fedoraproject.org&gt;
Tested-by: Luya Tshimbalanga &lt;luya@fedoraproject.org&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / EC: Fix regression related to triggering source of EC event handling</title>
<updated>2017-11-30T08:40:39+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2017-09-26T08:54:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3fe36d0c58a2a786308563163a999943bdc7b8b2'/>
<id>urn:sha1:3fe36d0c58a2a786308563163a999943bdc7b8b2</id>
<content type='text'>
commit 53c5eaabaea9a1b7a96f95ccc486d2ad721d95bb upstream.

Originally the Samsung quirks removed by commit 4c237371 can be covered
by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956
changed ec_freeze_events=Y back to N, making this problem re-surface.

Actually, if commit e923e8e7 is robust enough, we can freely change
ec_freeze_events mode, so this patch fixes the issue by improving
commit e923e8e7.

Related commits listed in the merged order:

 Commit: e923e8e79e18fd6be9162f1be6b99a002e9df2cb
 Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected
          after event is enabled

 Commit: 4c237371f290d1ed3b2071dd43554362137b1cce
 Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk

 Commit: 9c40f956ce9b331493347d1b3cb7e384f7dc0581
 Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix
          a regression

This patch not only fixes the reported post-resume EC event triggering
source issue, but also fixes an unreported similar issue related to the
driver bind by adding EC event triggering source in ec_install_handlers().

Fixes: e923e8e79e18 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled)
Fixes: 4c237371f290 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk)
Fixes: 9c40f956ce9b (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Reported-by: Alistair Hamilton &lt;ahpatent@gmail.com&gt;
Tested-by: Alistair Hamilton &lt;ahpatent@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmi: Mark all struct dmi_system_id instances const</title>
<updated>2017-09-14T09:59:30+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2017-09-14T09:59:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6faadbbb7f9da70ce484f98f72223c20125a1009'/>
<id>urn:sha1:6faadbbb7f9da70ce484f98f72223c20125a1009</id>
<content type='text'>
... and __initconst if applicable.

Based on similar work for an older kernel in the Grsecurity patch.

[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
</content>
</entry>
</feed>
