https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c1

--- Comment #1 from Artyom suse@rop.cx --- Created attachment 854025 --> https://bugzilla.suse.com/attachment.cgi?id=854025&action=edit dmesg -l err

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c3

--- Comment #3 from Artyom suse@rop.cx --- Created attachment 854027 --> https://bugzilla.suse.com/attachment.cgi?id=854027&action=edit lspci

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c4

--- Comment #4 from Artyom suse@rop.cx --- Created attachment 854030 --> https://bugzilla.suse.com/attachment.cgi?id=854030&action=edit hwinfo --all

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c6

--- Comment #6 from Artyom suse@rop.cx --- Created attachment 854041 --> https://bugzilla.suse.com/attachment.cgi?id=854041&action=edit xinput --list

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c7

Takashi Iwai tiwai@suse.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com

--- Comment #7 from Takashi Iwai tiwai@suse.com --- Please give the full dmesg output after the fresh boot, not only about errors, too.

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c9

--- Comment #9 from Artyom suse@rop.cx --- Created attachment 854044 --> https://bugzilla.suse.com/attachment.cgi?id=854044&action=edit inxi -v 2

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c10

--- Comment #10 from Takashi Iwai tiwai@suse.com --- This sounds like the case: https://bugzilla.kernel.org/show_bug.cgi?id=211553

Does the workaround suggested there work with yours? (either the dynamic re-binding or blacklisting).

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c12

--- Comment #12 from Artyom suse@rop.cx --- Created attachment 854049 --> https://bugzilla.suse.com/attachment.cgi?id=854049&action=edit dmesg on fedora

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c14

Artyom suse@rop.cx changed:

What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?

--- Comment #14 from Artyom suse@rop.cx --- But touchpad not working after suspending laptop

# modprobe -r psmouse modprobe: FATAL: Module psmouse is builtin.

# rmmod i2c_hid rmmod: ERROR: Module i2c_hid is in use by: i2c_hid_acpi

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c16

--- Comment #16 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #15)

How about rebinding?

echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind

You can try the above while the touchpad is working, and verify that the first call stops the touchpad and the second restores. If that works, try the same after the resume. It might be a different file name than i2c_hid on the recent system, so check the path beforehand. (e.g. on my 5.16-rc kernel, it's i2c_hid_acpi).

bash: /sys/bus/i2c/drivers/i2c_hid/unbind: No such file or directory

localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind

(In reply to Takashi Iwai from comment #15)

How about rebinding?

echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid/bind

You can try the above while the touchpad is working, and verify that the first call stops the touchpad and the second restores. If that works, try the same after the resume. It might be a different file name than i2c_hid on the recent system, so check the path beforehand. (e.g. on my 5.16-rc kernel, it's i2c_hid_acpi).

When touchpad is working (blacklisted elan) echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind Disables echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Restores (on my 5.15.3 kernel, it's i2c_hid_acpi too)

When touchpad is not working (delete blacklist) localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind bash: echo: write error: No such device localhost:/ # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind bash: echo: write error: Device or resource busy

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c18

--- Comment #18 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #17)

Without the blacklist, you need to unbind the elantech driver at first, then bind to the hid_i2c_acpi.

echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/elan_i2c/unbind echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind

Yes, that fixed, thanks (unbind elan and bind i2c_hid)

(In reply to Takashi Iwai from comment #17)

And, my question was: what happens if you re-bind the i2c-hid-acpi driver after the resume where the touchpad doesn't work any longer. Does it make the touchpad working again?

Seems rebinding is working, but after every rebind it resets touchpad settings

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c20

--- Comment #20 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #19)

OK, then it's about the PM problem of i2c-hid stuff.

I'm building a test kernel to ignore wakeup capability of the device to enforce the power up at resume. The test kernel is being built in OBS home:tiwai:bsc1193064 repo. Once after the build finishes, it'll be available at http://download.opensuse.org/repositories/home:/tiwai:/bsc1193064/standard/

Please check it out later. Note that it's an unofficial build, hence it won't boot with Secure Boot.

I did: rpm -ivh kernel-default-5.15.5-1.1.gafe3127.x86_64.rpm, reboot, uname -r 5.15.5-1.gafe3127-default

But seems that problem still there ..

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c22

--- Comment #22 from Artyom suse@rop.cx --- I installed all .rpm's

rpm -qa | grep gafe3127

kernel-devel-5.15.5-1.1.gafe3127.noarch kernel-default-devel-5.15.5-1.1.gafe3127.x86_64 kernel-default-5.15.5-1.1.gafe3127.x86_64 kernel-source-vanilla-5.15.5-1.1.gafe3127.noarch

I seems still no result

grub.cfg: linuxefi /boot/vmlinuz-5.15.5-1.gafe3127-default root=/dev/mapper/system-root ${extra_cmdline} splash=silent quiet mitigations=auto initrdefi /boot/initrd-5.15.5-1.gafe3127-default

(automatically generated by first rpm file, which is kernel-default-5.15.5-1.1.gafe3127.x86_64.rpm)

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c24

--- Comment #24 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #23)

Hrm, my kernel merely changed the suspend/resume functions and nothing else, so the behavior change except for suspend/resume isn't expected. And, it doesn't change the binding, so the blacklist is still necessary. It was asked only for testing the suspend/resume problem.

You should install only kernel-default.rpm, nothing else. At easiest, download kernel-default-5.15*.rpm from the URL and install it manually via zypper install.

Oh, my bad... My current fix is disabling touchpad service on startup (backgroud services on kde) - then it doesn't disable after suspend :) but fix for that would be too cool because in my case touchpad is enabled in suspend mode (it still consume electricity), also it's not possible to run this service manually (failed to start touchpad service) Also there strange enabled status when it broken For fixing after suspend/resume needs (maybe your kernel unbind elan_i2c?) # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Maybe problem with touchpad service ?

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c26

--- Comment #26 from Artyom suse@rop.cx --- Created attachment 854096 --> https://bugzilla.suse.com/attachment.cgi?id=854096&action=edit strange touchpad enabled status

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c28

--- Comment #28 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #27)

(In reply to Artyom from comment #24)

...

(In reply to Takashi Iwai from comment #23)

...

Hrm, my kernel merely changed the suspend/resume functions and nothing else, so the behavior change except for suspend/resume isn't expected. And, it doesn't change the binding, so the blacklist is still necessary. It was asked only for testing the suspend/resume problem.

You should install only kernel-default.rpm, nothing else. At easiest, download kernel-default-5.15*.rpm from the URL and install it manually via zypper install.

Oh, my bad... My current fix is disabling touchpad service on startup (backgroud services on kde) - then it doesn't disable after suspend :) but fix for that would be too cool because in my case touchpad is enabled in suspend mode (it still consume electricity), also it's not possible to run this service manually (failed to start touchpad service) Also there strange enabled status when it broken For fixing after suspend/resume needs (maybe your kernel unbind elan_i2c?) # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind # echo -n "i2c-ELAN0000:00" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind Maybe problem with touchpad service ?

Is this behavior (jumping pointer?) with the unpatched kernel? I expected that the patch may influence on this.

In anyway, if not done yet, please check the following with the patched kernel:

• Boot with the blacklist
• Try suspend / resume without re-binding

and let me know which problem is present.

FWIW, Fedora kernel "works" because the device is bound with i2c-hid, not elantech. Maybe they have some workaround in it or it's just a matter of device binding order that casually worked. But the suspend/resume problem should remain with them unless any fix is applied.

No, this on both kernels, but this was not the case in Fedora (there it were a easy way to rebind)

The problems is present :( At the moment I have not noticed the difference between the kernels

Yes, looks like that, but all (including fedora) have a problem with touchpad service

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c30

--- Comment #30 from Artyom suse@rop.cx --- I still have this problem on TW, but currently see in dmesg ("d" instead of "0") elan_i2c i2c-ELAN0000:00: invalid report id data (d) So, blocking in modprobe is still needed

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c32

--- Comment #32 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #31)

OK, I'm building another test kernel in the same OBS repo home:tiwai:bsc1193064. At this time, it's a test patch to avoid binding with elan-i2c, so it should work without blacklist. Please give it a try once after the build finishes. It'll be based on 5.16.4.

It's still binding with elan-i2c :(

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c34

Artyom suse@rop.cx changed:

What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suse@rop.cx) |

--- Comment #34 from Artyom suse@rop.cx --- (In reply to Takashi Iwai from comment #31)

OK, I'm building another test kernel in the same OBS repo home:tiwai:bsc1193064. At this time, it's a test patch to avoid binding with elan-i2c, so it should work without blacklist. Please give it a try once after the build finishes. It'll be based on 5.16.4.

It still binding with elan-i2c(In reply to Takashi Iwai from comment #33)

There was a wrong DMI matching field, hence it didn't hit the list. Now a new test kernel (5.16.5) is being built in the same OBS repo with the revised patch. Please check it later.

Yay! Thank you, it works correctly now Will this patch get into the TW and Leap (15.4) default kernel?

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c53

--- Comment #53 from Swamp Workflow Management swamp@suse.de --- SUSE-SU-2022:2615-1: An update that solves 48 vulnerabilities, contains 26 features and has 202 fixes is now available.

Category: security (important) Bug References: 1055117,1061840,1065729,1071995,1089644,1103269,1118212,1121726,1137728,1156395,1157038,1157923,1175667,1179439,1179639,1180814,1183682,1183872,1184318,1184924,1187716,1188885,1189998,1190137,1190208,1190336,1190497,1190768,1190786,1190812,1191271,1191663,1192483,1193064,1193277,1193289,1193431,1193556,1193629,1193640,1193787,1193823,1193852,1194086,1194111,1194191,1194409,1194501,1194523,1194526,1194583,1194585,1194586,1194625,1194765,1194826,1194869,1195099,1195287,1195478,1195482,1195504,1195651,1195668,1195669,1195775,1195823,1195826,1195913,1195915,1195926,1195944,1195957,1195987,1196079,1196114,1196130,1196213,1196306,1196367,1196400,1196426,1196478,1196514,1196570,1196723,1196779,1196830,1196836,1196866,1196868,1196869,1196901,1196930,1196942,1196960,1197016,1197157,1197227,1197243,1197292,1197302,1197303,1197304,1197362,1197386,1197501,1197601,1197661,1197675,1197761,1197817,1197819,1197820,1197888,1197889,1197894,1197915,1197917,1197918,1197920,1197921,1197922,1197926,119800 9,1198010,1198012,1198013,1198014,1198015,1198016,1198017,1198018,1198019,1198020,1198021,1198022,1198023,1198024,1198027,1198030,1198034,1198058,1198217,1198379,1198400,1198402,1198412,1198413,1198438,1198484,1198577,1198585,1198660,1198802,1198803,1198806,1198811,1198826,1198835,1198968,1198971,1199011,1199024,1199035,1199046,1199052,1199063,1199163,1199173,1199260,1199314,1199390,1199426,1199433,1199439,1199482,1199487,1199505,1199507,1199605,1199611,1199626,1199631,1199650,1199657,1199674,1199736,1199793,1199839,1199875,1199909,1200015,1200019,1200045,1200046,1200144,1200205,1200211,1200259,1200263,1200284,1200315,1200343,1200420,1200442,1200475,1200502,1200567,1200569,1200571,1200572,1200599,1200600,1200608,1200611,1200619,1200692,1200762,1200763,1200806,1200807,1200808,1200809,1200810,1200812,1200815,1200816,1200820,1200822,1200824,1200825,1200827,1200828,1200829,1200830,1200845,1200882,1200925,1201050,1201160,1201171,1201177,1201193,1201196,1201218,1201222,1201228,1201251,150 300 CVE References: CVE-2021-26341,CVE-2021-33061,CVE-2021-4204,CVE-2021-44879,CVE-2021-45402,CVE-2022-0264,CVE-2022-0494,CVE-2022-0617,CVE-2022-1012,CVE-2022-1016,CVE-2022-1184,CVE-2022-1198,CVE-2022-1205,CVE-2022-1508,CVE-2022-1651,CVE-2022-1652,CVE-2022-1671,CVE-2022-1679,CVE-2022-1729,CVE-2022-1734,CVE-2022-1789,CVE-2022-1852,CVE-2022-1966,CVE-2022-1972,CVE-2022-1974,CVE-2022-1998,CVE-2022-20132,CVE-2022-20154,CVE-2022-21123,CVE-2022-21125,CVE-2022-21127,CVE-2022-21166,CVE-2022-21180,CVE-2022-21499,CVE-2022-2318,CVE-2022-23222,CVE-2022-26365,CVE-2022-26490,CVE-2022-29582,CVE-2022-29900,CVE-2022-29901,CVE-2022-30594,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742,CVE-2022-33743,CVE-2022-33981,CVE-2022-34918 JIRA References: SLE-13513,SLE-13521,SLE-15442,SLE-17855,SLE-18194,SLE-18234,SLE-18375,SLE-18377,SLE-18378,SLE-18382,SLE-18385,SLE-18901,SLE-18938,SLE-18978,SLE-19001,SLE-19026,SLE-19242,SLE-19249,SLE-19253,SLE-19924,SLE-21315,SLE-23643,SLE-24072,SLE-24093,SLE-24350,SLE-24549 Sources used: openSUSE Leap 15.4 (src): kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.1 SUSE Linux Enterprise Module for Public Cloud 15-SP4 (src): kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c55

Takashi Iwai tiwai@suse.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tiwai@suse.com) |needinfo?(suse@rop.cx)

--- Comment #55 from Takashi Iwai tiwai@suse.com --- My RFC patch wasn't taken, as we wanted a different approach: https://lore.kernel.org/all/s5hleyqwowl.wl-tiwai@suse.de/

It's a question whether the same situation still remains with the latest upstream.

Artyom, could you check whether the problem still appears when you install and boot with kernel-vanilla package?

https://bugzilla.suse.com/show_bug.cgi?id=1193064 https://bugzilla.suse.com/show_bug.cgi?id=1193064#c57

--- Comment #57 from Takashi Iwai tiwai@suse.com --- Thanks for confirmation. So we still need to work on the proper fix. This has to be discussed with the upstream again.

Meanwhile we can keep the downstream fix patch for now; it's pretty safe and has been working.