lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Dec 2015 10:53:29 +0100
From:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:	Nish Aravamudan <nish.aravamudan@...il.com>
Cc:	Jiri Kosina <jikos@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andrew Duggan <aduggan@...aptics.com>,
	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	linux-input@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND] Lenovo Yoga 900 touchpad issues

On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
> Hi Jiri,
> 
> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina <jikos@...nel.org> wrote:
> > On Wed, 16 Dec 2015, Mika Westerberg wrote:
> >
> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail settings
> >> > to not use HTML.]
> >> >
> >> > I have recently purchased a Lenovo Yoga 900 and most everything is working
> >> > with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 applied
> >> > to enable the touchpad itself), I am seeing two issues:
> >> >
> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r i2c-hid;
> >> >  modprobe i2c-hid` "fixes" it.
> >> >
> >> > The kernel emits:
> >> >
> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
> >> >
> >> > During the resume. So perhaps this is a timing issue (given that once
> >> > resumed, the
> >> > module reload does work?).
> >>
> >> Linus noticed this as well and Jiri suggested the below patch which
> >> seemed to fix the issue (although it increased resume time a bit).
> >>
> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
> >> I'm still waiting for it (sloow big corporation bureaucracy takes some
> >> time to get things purchased outside).
> >>
> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> >> index 55d8f9d..52dd03a0 100644
> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
> >>       struct i2c_client *client = to_i2c_client(dev);
> >>       struct i2c_hid *ihid = i2c_get_clientdata(client);
> >>       struct hid_device *hid = ihid->hid;
> >> -     int wake_status;
> >> +     int wake_status, tries = 3;
> >>
> >>       enable_irq(ihid->irq);
> >> -     ret = i2c_hid_hwreset(client);
> >> +
> >> +     do {
> >> +             ret = i2c_hid_hwreset(client);
> >> +             if (ret)
> >> +                     msleep(1000);
> >> +     } while (tries-- > 0 && ret);
> >> +
> >>       if (ret)
> >>               return ret;
> >
> > As a possible alternative, please test the patch above on top of for-next
> > branch of
> >
> >         git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
> >
> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
> > asynchronously") and knowing whether that changes something might be
> > interesting datapoint as well.
> 
> What should I be looking for to be different wrt. that tree? Should I
> not see the failure to reset the device? Or would it be (relatively)
> speedier than the stock kernel?
> 

Basically, does the resume time gets better? Linus experienced something
like 9 secs of resume before this patch, and now I hope it should be
saner (the touchpad might still be a little bit long to respond).

Also, we have a bug report concerning this laptop and it looks like the
i2c controller needs to be updated (see
https://bugzilla.redhat.com/show_bug.cgi?id=1275718).

I am not entirely sure why those on the rhbz needs to update the i2c
controller while you don't have to, but it may also be worth checking if
the i2c patch series mentioned in this rhbz (comment #20) fixes by itself
the resume issue (without Jiri's patch).

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ