Bug 1275718

Looks like this laptop might need to be blacklisted like: 

http://www.spinics.net/lists/linux-i2c/msg21329.html

I tried a simple: 

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3dd2de3..6d28585 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -24,6 +24,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/i2c.h>
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
@@ -51,6 +52,21 @@ static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
 }
 
 #ifdef CONFIG_ACPI
+/*
+ * The HCNT/LCNT information coming from ACPI should be the most accurate
+ * for given platform. However, some systems get it wrong. On such systems
+ * we get better results by calculating those based on the input clock.
+ */
+static const struct dmi_system_id dw_i2c_no_acpi_params[] = {
+       {
+               .ident = "Lenovo YOGA 900-13ISK",
+               .matches = {
+                       DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                       DMI_MATCH(DMI_PRODUCT_NAME, "80MK"),
+               },
+       },
+       { }
+};
 static void dw_i2c_acpi_params(struct platform_device *pdev, char method[],
                               u16 *hcnt, u16 *lcnt, u32 *sda_hold)
 {
@@ -58,6 +74,9 @@ static void dw_i2c_acpi_params(struct platform_device *pdev, char method[],
        acpi_handle handle = ACPI_HANDLE(&pdev->dev);
        union acpi_object *obj;
 
+       if (dmi_check_system(dw_i2c_no_acpi_params))
+               return;
+
        if (ACPI_FAILURE(acpi_evaluate_object(handle, method, NULL, &buf)))
                return;
 
With no real luck. dmesg still has: 

[10402.993959] idma64 idma64.1: idma64_irq: status=0x0
[10402.993983] idma64 idma64.1: idma64_irq: status=0x0
[10402.994212] i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
[10402.994218] i2c_hid i2c-SYNA2B29:00: hid_descr_cmd failed
[10403.019671] idma64 idma64.2: idma64_irq: status=0x0
[10403.019703] idma64 idma64.2: idma64_irq: status=0x0
[10403.019768] i2c_designware i2c_designware.2: i2c_dw_handle_tx_abort: lost arbitration
[10403.019774] i2c_hid i2c-ELAN21EF:00: hid_descr_cmd failed

Hi,

Looks like this is one for Benjamin Tissoires to take a look at, he is already on the Cc, I'll drop him a mail asking to take a look.

Regards,

Hans

(In reply to Hans de Goede from comment #3)
> Hi,
> 
> Looks like this is one for Benjamin Tissoires to take a look at, he is
> already on the Cc, I'll drop him a mail asking to take a look.
>

No, this one is not mine, it is a i2c designware problem. If the request of the hid descriptor fails, there is nothing we can do at the input level.

As Kevin said and tried, there is something that needs to be done in the i2c module, but I have no ideas what.

Alright. Thanks for looking. 

Any ideas who might be able to look at it? Or should I post to the i2c-devel list upstream?

You might get a better chance by talking directly to i2c-devel, yes. Sorry I can not help more.

This patch gets it working, but is likely not upstreamable due to magic numbers: 

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 809579e..826e893 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -105,6 +105,7 @@ static int dw_i2c_acpi_configure(struct platform_device *pdev)
        dw_i2c_acpi_params(pdev, "SSCN", &dev->ss_hcnt, &dev->ss_lcnt, NULL);
        dw_i2c_acpi_params(pdev, "FMCN", &dev->fs_hcnt, &dev->fs_lcnt,
                           &dev->sda_hold_time);
+       dev->sda_hold_time = 30;
 
        return 0;
 }

What is the status of this ticket?  Is it actionable and if so, when can I install the new kernel which has the fix?

@Kevin - Would you mind telling me how you built the kernel with the fix?  I followed the instructions for building a custom kernel outlined in the following link to no avail

    https://fedoraproject.org/wiki/Building_a_custom_kernel

(In reply to nadersalehi1 from comment #8)
> What is the status of this ticket?  Is it actionable and if so, when can I
> install the new kernel which has the fix?

The above one liner is not a fix. It's a hack, and so won't likely be in any kernel. 

However, upstream folks are working on a actual fix. 
They have posted a series of patches:
http://marc.info/?l=linux-kernel&m=144889673109698&w=2
that has a real upstreamable fix. Unfortunately, thats too invasive to make 4.4.0 most likely, so it will be in 4.5 probibly. 
> 
> @Kevin - Would you mind telling me how you built the kernel with the fix?  I
> followed the instructions for building a custom kernel outlined in the
> following link to no avail
> 
>     https://fedoraproject.org/wiki/Building_a_custom_kernel

I got a git checkout of the fedora kernel: 

git clone https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
cd fedora/drivers/i2c/busses/
edit i2c-designware-platdrv.c and apply the one line patch/change.
make sure you have kernel-devel installed
make -C /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/build M=/home/kevin/git/fedora/drivers/i2c/busses i2c-designware-platform.ko
(with version and patch changed to your setup)
sudo cp i2c-designware-platform.ko /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/kernel/drivers/i2c/busses/i2c-designware-platform.ko
sudo rm -f /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/kernel/drivers/i2c/busses/i2c-designware-platform.ko.xz
sudo depmod -a 4.4.0-0.rc2.git2.1.fc24.x86_64
(again for your kernel version)
then boot into that kernel.

I have tried the instructions mentioned here, however I am unable to get the touchscreen or the touchpad to work, is there a chance I can a bit more troubleshooting as to why it's not working for me ?

I have tried the instructions mentioned here, however I am unable to get the touchscreen or the touchpad to work, is there a chance I can a bit more troubleshooting as to why it's not working for me ?

(In reply to Hany from comment #11)
> I have tried the instructions mentioned here, however I am unable to get the
> touchscreen or the touchpad to work, is there a chance I can a bit more
> troubleshooting as to why it's not working for me ?

I also was not able to get the touchpad working with the oneliner fix to kernel-4.2.6-301.fc23.x86_64. I did get it working on 4.4.0 kernel. First I installed the rawhide nodebug kernel by installing the repo from here:

https://fedoraproject.org/wiki/RawhideKernelNodebug

After installing the new kernel, I then grabbed the corresponding source and built the i2c-designware-platform.ko module with the oneliner patch and dropped it into place as described in Comment #9.

The rawhide kernel-4.4.0-0.rc3.git1.2.fc24.x86_64 also has both bits for the wireless as well (bug #1275490), while the fc23 kernel update missed the PCI ID portion of that fix. There are other issues I was having with the Yoga 900 under the fc23 kernel that I think have been resolved in the rawhide kernel.

Hope that helps.

The Fedora 4.2.x kernels are missing (at least) MFD_INTEL_LPSS_ACPI being set. (which actually may not even have been added until 4.3.x). So you really do need to go with a rawhide kernel for this, at least right now. ;(

I have followed Kevin's instructions to the T and still no luck .. down to the same exact kernel version, what happens is,
 3 warnings about 3 functions ( i2c_dw_xfer, i2c_dw_func, i2c_dw_isr ) while building the module reporting as undefined..
 after copying and depmod -a uname -r it doesn't complain but lsmod | grep i2c isn't listing the module.
 modprobe --force i2c-desginware-platform errors with "exec format error"
 dmesg | grep i2c is reporting "module verification failed: signature and/or required key missing - tainting kernel".

Casey or Kevin, please help or point to where the issue might be and why it would work for you but not on my machine ?

Possible issues: 

1. Make sure you have the kernel-devel subpackage installed for the same version as your kernel?

2. Make sure secure boot is off (hit f2 on boot to get to firmware, go to the secure boot option and set it to off).

Thank you Kevin, right now it's booting off Legacy mode, no even UEFI support which effectively turned off secure boot which I turned off manually as well. the inly thing I could have done differently is to installing the kernel from a downloaded RPM package and running it off the USB stick, which is possible to be corrupt ... I will use rawhide to get the same exact version you used in your steps and hopefully that would work this time, I will report back.

(In reply to Alphakarem from comment #16)
> Thank you Kevin, right now it's booting off Legacy mode, no even UEFI
> support

That *might* be a problem in itself, these new type i2c touchpads / touchscreens rely somewhat on firmware support, and it may be that in legacy mode some of the relevant ACPI tables are different or just not there.

So if you still cannot get things to work after reproducing Kevin's approach 100% you should probably try switching back to booting in UEFI mode.

While the hack/fix from Comment #7 will get the touchpad working on boot, if often breaks after suspend/resume. Reloading the i2c-designware-platform module fixes the problem. I'm doing this from /usr/lib/systemd/system-sleep/fixtouchpad.sh:

case "$1" in
    pre)
        modprobe -r i2c-designware-platform
        ;;
    post)
        modprobe i2c-designware-platform
        ;;
    *)
        ;;
esac


Hope this helps others until things are fixed upstream.

Hi Folks,

I had a chance to play around with Kevin's instructions and finally managed to get the trackpad and touchscreen working.  It needed a little tweaking.

@Kevin - Thank you so much for doing the heavy lifting.  I can now wait for the official Fedora release.

> git clone https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
> cd fedora/drivers/i2c/busses/
> edit i2c-designware-platdrv.c and apply the one line patch/change.
> make sure you have kernel-devel installed
> make -C /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/build
> M=/home/kevin/git/fedora/drivers/i2c/busses i2c-designware-platform.ko
> (with version and patch changed to your setup)
> sudo cp i2c-designware-platform.ko
> /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/kernel/drivers/i2c/busses/i2c-
> designware-platform.ko
> sudo rm -f
> /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/kernel/drivers/i2c/busses/i2c-
> designware-platform.ko.xz

sudo xz -z /lib/modules/4.4.0-0.rc2.git2.1.fc24.x86_64/kernel/drivers/i2c/busses/i2c-
> designware-platform.ko (or whatever your version is)

> sudo depmod -a 4.4.0-0.rc2.git2.1.fc24.x86_64

sudo modprobe -r i2c_designware_platform
sudo modprobe i2c_designware_platform

> (again for your kernel version)
> then boot into that kernel.

Josh, I am no expert in linux-pm, but I made a quick review of the patches sent by Andy Shevchenko. They are in the pm maintainer tree[1] and scheduled for 4.5 as Rafael said. I think they should be safe enough to be included in Fedora (probably only rawhide).

I do not see any revert or later commit which would assume there is an error in the series, so I am in favor of backporting the 16 patches in the Fedora rawhide kernel.

[1] https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=e3f9e299bf94298ddd8beb63c0786a4d7766dc86

I hae followed Casey's pointers and they worked, have been waiting to test on a couple more rawhide kernels and so far all is good. I put this script as a quick way to those how are changing Kernels / want an easy way to build the support or those who are not very technical or new to Linux in general, here it is in case anyone is interested.

sudo or root to run the script. put what's below in a file and name anything, give it execute permissions like : chmod 744 <filename> then run it from terminal ( assuming your are in the directory where the file is) like this ./<filename>

dnf download --source kernel
ver=$(uname -r | sed "s/\.`arch` *$//")
#su -c 'dnf builddep kernel-`$ver`.src.rpm'
sudo dnf builddep kernel-`echo $ver`.src.rpm
rpm -Uvh kernel-`echo $ver`.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ../BUILD
cd kernel*/linux*/drivers/i2c/busses/
sed -i "s/\(&dev->sda_hold_time);\)/\1\n\tdev->sda_hold_time = 30;/" i2c-designware-platdrv.c
make -C /lib/modules/`uname -r`/build M=`pwd` i2c-designware-platform.ko
sudo cp i2c-designware-platform.ko /lib/modules/`uname -r`/kernel/drivers/i2c/busses/i2c-designware-platform.ko
sudo mv /lib/modules/`uname -r`/kernel/drivers/i2c/busses/i2c-designware-platform.ko.xz /lib/modules/`uname -r`/kernel/drivers/i2c/busses/i2c-designware-platform.ko.xz.old
sudo depmod -a `uname -r`
sudo modprobe -r  i2c-designware-platform && modprobe i2c-designware-platform

(In reply to Benjamin Tissoires from comment #20)
> Josh, I am no expert in linux-pm, but I made a quick review of the patches
> sent by Andy Shevchenko. They are in the pm maintainer tree[1] and scheduled
> for 4.5 as Rafael said. I think they should be safe enough to be included in
> Fedora (probably only rawhide).
> 
> I do not see any revert or later commit which would assume there is an error
> in the series, so I am in favor of backporting the 16 patches in the Fedora
> rawhide kernel.
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/
> ?h=bleeding-edge&id=e3f9e299bf94298ddd8beb63c0786a4d7766dc86

I _finally_ got around to testing these this weekend as well and they seem to work fine here. 
(scratch build with patches applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=12178401 )

I dropped the 16 patches in rawhide. Should be in the next release (Wed or Thu)

I can confirm touchpad/touchscreen working on rawhide kernel-4.4.0-0.rc5.git1.2.fc24.x86_64 on F23 without any further modification.

kernel-4.4.0-0.rc5.git3.1.fc24.x86_64 works

Thanks for all the testing. The patches should be coming in a kernel.org release in January (assuming they come in for the 4.5 merge window). I'm going to mark this as closed for rawhide.

(In reply to Laura Abbott from comment #23)
> I dropped the 16 patches in rawhide. Should be in the next release (Wed or
> Thu)

These patches broke the touchpad on my Dell Inspiron 7559. The touchpad, and Elantech touchpad hasn't worked on all rawhide kernels since kernel-4.4.0-0.rc4.git4.1.fc24.x86_64. Please let me know if you need more info.

Hmmmm, can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=12410556 once it finishes? This is a scratch build with those 16 patches removed.

(In reply to Laura Abbott from comment #28)
> Hmmmm, can you try
> http://koji.fedoraproject.org/koji/taskinfo?taskID=12410556 once it
> finishes? This is a scratch build with those 16 patches removed.

Yes, this scratch build works for me, I am able to use the touchpad with kernel-4.4.0-0.rc8.git0.1.noyoga.fc24.x86_64.rpm as with kernel-4.4.0-0.rc4.git4.1.fc24.x86_64.
Thanks.

Great, thanks for confirming. I'm going to drop the patches from rawhide today and see if I can find a thread upstream to follow up on.

The upstream maintainer mentioned there were a few fixes that came in, can you test http://koji.fedoraproject.org/koji/taskinfo?taskID=12426934 once it finishes building?

(In reply to Laura Abbott from comment #31)
> The upstream maintainer mentioned there were a few fixes that came in, can
> you test http://koji.fedoraproject.org/koji/taskinfo?taskID=12426934 once it
> finishes building?

I tested the above build - kernel-4.4.0-0.rc8.git0.1.yogatestfixes.fc24.x86_64.rpm -  and no, the touchpad doesn't work with it. A related message that appeared in dmesg, which I think might be useful is;
"psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6"

Hi,

(In reply to Deji Akingunola from comment #32)
> (In reply to Laura Abbott from comment #31)
> > The upstream maintainer mentioned there were a few fixes that came in, can
> > you test http://koji.fedoraproject.org/koji/taskinfo?taskID=12426934 once it
> > finishes building?
> 
> I tested the above build -
> kernel-4.4.0-0.rc8.git0.1.yogatestfixes.fc24.x86_64.rpm -  and no, the
> touchpad doesn't work with it. A related message that appeared in dmesg,
> which I think might be useful is;
> "psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6"

Can you please run "sudo evemu-describe" on a working kernel and then select the number for your
touchpad and copy and paste the output (including the list of devices) here ?

I'm wondering what sort of bus your touchpad is using. If it is a ps/2 touchpad then this patch-set should not affect it.

(In reply to Hans de Goede from comment #33)

> Can you please run "sudo evemu-describe" on a working kernel and then select
> the number for your
> touchpad and copy and paste the output (including the list of devices) here ?
> 
> I'm wondering what sort of bus your touchpad is using. If it is a ps/2
> touchpad then this patch-set should not affect it.

[deji@logos ~]$ sudo evemu-describe
Available devices:
/dev/input/event0:	Sleep Button
/dev/input/event1:	Power Button
/dev/input/event2:	Lid Switch
/dev/input/event3:	Power Button
/dev/input/event4:	AT Translated Set 2 keyboard
/dev/input/event5:	Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)
/dev/input/event6:	ETPS/2 Elantech Touchpad
/dev/input/event7:	Video Bus
/dev/input/event8:	Video Bus
/dev/input/event9:	Atmel Atmel maXTouch Digitizer
/dev/input/event10:	DELL Wireless hotkeys
/dev/input/event11:	HDA Intel PCH Headphone Mic
/dev/input/event12:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event13:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event14:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event15:	Dell WMI hotkeys
/dev/input/event16:	Integrated_Webcam_HD
Select the device event number [0-16]: 6
# EVEMU 1.3
# Kernel: 4.4.0-0.rc4.git4.1.fc24.x86_64
# DMI: dmi:bvnDellInc.:bvr1.1.3:bd11/05/2015:svnDellInc.:pnInspiron7559:pvr1.1.3:rvnDellInc.:rn0H0CC0:rvrA00:cvnDellInc.:ct8:cvrNotSpecified:
# Input device name: "ETPS/2 Elantech Touchpad"
# Input device ID: bus 0x11 vendor 0x02 product 0x0e version 0000
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#   Event type 1 (EV_KEY)
#     Event code 272 (BTN_LEFT)
#     Event code 325 (BTN_TOOL_FINGER)
#     Event code 330 (BTN_TOUCH)
#     Event code 333 (BTN_TOOL_DOUBLETAP)
#     Event code 334 (BTN_TOOL_TRIPLETAP)
#     Event code 335 (BTN_TOOL_QUADTAP)
#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value   2296
#       Min        0
#       Max     3220
#       Fuzz       0
#       Flat       0
#       Resolution 31
#     Event code 1 (ABS_Y)
#       Value   1538
#       Min        0
#       Max     2422
#       Fuzz       0
#       Flat       0
#       Resolution 31
#     Event code 24 (ABS_PRESSURE)
#       Value      0
#       Min        0
#       Max      255
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 28 (ABS_TOOL_WIDTH)
#       Value      5
#       Min        0
#       Max       15
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 47 (ABS_MT_SLOT)
#       Value      3
#       Min        0
#       Max        4
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 48 (ABS_MT_TOUCH_MAJOR)
#       Value      0
#       Min        0
#       Max     2415
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 53 (ABS_MT_POSITION_X)
#       Value      0
#       Min        0
#       Max     3220
#       Fuzz       0
#       Flat       0
#       Resolution 31
#     Event code 54 (ABS_MT_POSITION_Y)
#       Value      0
#       Min        0
#       Max     2422
#       Fuzz       0
#       Flat       0
#       Resolution 31
#     Event code 57 (ABS_MT_TRACKING_ID)
#       Value      0
#       Min        0
#       Max    65535
#       Fuzz       0
#       Flat       0
#       Resolution 0
#     Event code 58 (ABS_MT_PRESSURE)
#       Value      0
#       Min        0
#       Max      255
#       Fuzz       0
#       Flat       0
#       Resolution 0
# Properties:
#   Property  type 0 (INPUT_PROP_POINTER)
#   Property  type 2 (INPUT_PROP_BUTTONPAD)
N: ETPS/2 Elantech Touchpad
I: 0011 0002 000e 0000
P: 05 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 01 00 00 00 00 00
B: 01 20 e4 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 00 00 00 00 00 00 00 00
B: 03 03 00 00 11 00 80 61 06
B: 04 00 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 14 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
A: 00 0 3220 0 0 31
A: 01 0 2422 0 0 31
A: 18 0 255 0 0 0
A: 1c 0 15 0 0 0
A: 2f 0 4 0 0 0
A: 30 0 2415 0 0 0
A: 35 0 3220 0 0 31
A: 36 0 2422 0 0 31
A: 39 0 65535 0 0 0
A: 3a 0 255 0 0 0

Hmm, so you've a ps/2 touchpad, weird that this patch-set influences it then.

Deji, can you provide full dmesg of working and non-working cases? Also please attach acpidump from that machine.

Created attachment 1112458 [details]
dmesg from a working kernel

Created attachment 1112459 [details]
dmesg from a non-working kernel

Please note that the non-working kernel is the one with the patches referenced in comment #28 above.

Created attachment 1112461 [details]
acpidump

Thanks for the logs. What happens is the following:

- without the patches from comment #28, you also have the bug reported here:
[    8.358642] i2c_designware i2c_designware.0: i2c_dw_handle_tx_abort: lost arbitration
[    8.358698] i2c_hid i2c-ELAN1010:00: hid_descr_cmd failed
in the "working" touchpad dmesg.
- when the designware controller fails, the touchpad keeps the PS/2 mode and is functional
- once the patches are present, your touchpad switches to the enhanced mode over I2C, but fails. PS/2 is disabled by the touchpad, and hid-multitouch doesn't seem to be driving properly the touchpad.

Deji, could you please attach a hid-recorder[1] of the node "ELAN1010:00 04F3:3012" when the kernel is with the patches mentioned in this bug.
Please try to use the touchpad while hid-recorder is running so we can see if events are coming through the i2c channel or not.



[1] install hid-replay as per http://bentiss.github.io/hid-replay-docs/

Created attachment 1112497 [details]
hid-recorder log

Here is the hid-recorder event log as requested, generated using kernel-4.4.0-0.rc8.git0.1.yogatestfixes.fc24.x86_64.rpm from comment #31.

OK, the device is still in the mouse emulation mode.
The goods news is that the device is working as it sends events. Not just the correct events :)

Would you mind opening a separate bug for this issue?

I think we can consider this bug (the designware controller failing) fixed. It's unfortunate your touchpad is not working, but it is a different bug I'd like to track separately.

I will leave it to the maintainer to close the bug, and will fill a new bug as suggested once the patched kernel hit rawhide again. Thanks.

Go ahead and file a bug for tracking right now.  I'm going to bring the patches for Yoga back in since there seems to be a good handle on what's going on.

Speaking for an ASUS Zenbook UX305CA (for which I was referred to this very bug):

kernel-4.5.0-0.rc7.git2.1.fc25 installed on F23 and the touchpad works flawlessly as far as I can tell!