Linux Input/HID development
 help / color / mirror / Atom feed
* Re: [PATCH v5] Input: add bu21029 touch driver
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-13 15:27 UTC (permalink / raw)
  To: Dmitry Torokhov, Rob Herring, Mark Rutland
  Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, hs@denx.de,
	andy.shevchenko@gmail.com, ZHU Yi (BT-FIR/ENG1-Zhu),
	Jonas Mark (BT-FIR/ENG1)

Hello Dmitry,

> > [PATCH v5] Input: add bu21029 touch driver
> >
> > Add Rohm BU21029 resistive touch panel controller support with I2C
> > interface.
> 
> Is the patch ready to be pushed upstream? Is there anything I still need to do?

I would like to kindly remind you of the BU21029 touch screen driver.
Could you please forward it to the mainline kernel?

Greetings,
Mark

 Mark Jonas

Building Technologies, Panel Software Fire (BT-FIR/ENG1) 
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118 
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster

^ permalink raw reply

* Re: [PATCH] HID: wacom: Correct logical maximum Y for 2nd-gen Intuos Pro large
From: Jiri Kosina @ 2018-06-13 13:44 UTC (permalink / raw)
  To: Jason Gerecke
  Cc: linux-input, Benjamin Tissoires, Ping Cheng, Aaron Skomra, stable,
	Jason Gerecke
In-Reply-To: <20180612204246.6623-1-killertofu@gmail.com>

On Tue, 12 Jun 2018, Jason Gerecke wrote:

> The HID descriptor for the 2nd-gen Intuos Pro large (PTH-860) contains
> a typo which defines an incorrect logical maximum Y value. This causes
> a small portion of the bottom of the tablet to become unusable (both
> because the area is below the "bottom" of the tablet and because
> 'wacom_wac_event' ignores out-of-range values). It also results in a
> skewed aspect ratio.
> 
> To fix this, we add a quirk to 'wacom_usage_mapping' which overwrites
> the data with the correct value.
> 
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> CC: stable@vger.kernel.org # v4.10+

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Jiri Kosina @ 2018-06-13 11:34 UTC (permalink / raw)
  To: Even Xu
  Cc: srinivas.pandruvada, benjamin.tissoires, linux-input,
	linux-kernel, stable
In-Reply-To: <1455221494-2915-1-git-send-email-even.xu@intel.com>

On Fri, 12 Feb 2016, Even Xu wrote:

> Current ISH driver only registers suspend/resume PM callbacks which don't
> support hibernation (suspend to disk). Basically after hiberation, the ISH
> can't resume properly and user may not see sensor events
> (for example: screen rotation may not work).
> 
> User will not see a crash or panic or anything except the following message
> in log:
> hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP device
> 
> So this patch adds support for S4/hiberbation to ISH by using the
> SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend
> and resume functions will now be used for both suspend to RAM and hibernation.
> 
> If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend
> and resume related functions won't be used, so mark them as __maybe_unused to
> clarify that this is the intended behavior, and remove #ifdefs for power
> management.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Even Xu <even.xu@intel.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Applied to hid.git#for-4.18/upstream-fixes. Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: [PATCH v5 2/4] resource: Use list_head to link sibling resource
From: Baoquan He @ 2018-06-13  6:55 UTC (permalink / raw)
  To: Julia Lawall
  Cc: brijesh.singh-5C7GfCeVMHo, thomas.lendacky-5C7GfCeVMHo,
	airlied-cv59FeDIM0c, linux-pci-u79uwXL29TY76Z2rM5mHXA,
	richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w,
	keith.busch-ral2JQCrhuEAvxtiuMwx3w,
	jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w,
	baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/,
	frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
	lorenzo.pieralisi-5wv7dgnIgG8, sthemmin-0li6OtcxBFHby3iVrkZq2A,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
	patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w,
	linux-input-u79uwXL29TY76Z2rM5mHXA,
	gustavo-THi1TnShQwVAfugRpC6u6w, dyoung-H+wXaHxf7aLQT0dZR+AlfA,
	kbuild-all-JC7UmRfGjtg, devicetree-u79uwXL29TY76Z2rM5mHXA,
	haiyangz-0li6OtcxBFHby3iVrkZq2A,
	maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
	jglisse-H+wXaHxf7aLQT0dZR+AlfA, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
	bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
	yinghai-DgEjT+Ai2ygdnm+yROfE0A,
	jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
	chris-YvXeqwSYzG2sTnJN9+BGXg, monstr-pSz03upnqPeHXe+LvDLADg,
	linux-parisc-u79uwXL29TY76Z2rM5mHXA,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
	kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w,
	devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, davem-fT/PcQaiUtJq0hI55+XSNA
In-Reply-To: <alpine.DEB.2.20.1806121708070.3334@hadrien>

On 06/12/18 at 05:10pm, Julia Lawall wrote:
> This looks wrong.  After a list iterator, the index variable points to a
> dummy structure.
> 
> julia
> 
> url:    https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180612-113600
> :::::: branch date: 7 hours ago
> :::::: commit date: 7 hours ago
> 
> >> kernel/resource.c:265:17-20: ERROR: invalid reference to the index variable of the iterator on line 253
> 
> # https://github.com/0day-ci/linux/commit/e906f15906750a86913ba2b1f08bad99129d3dfc
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout e906f15906750a86913ba2b1f08bad99129d3dfc
> vim +265 kernel/resource.c
> 
> ^1da177e4 Linus Torvalds 2005-04-16  247
> 5eeec0ec9 Yinghai Lu     2009-12-22  248  static void __release_child_resources(struct resource *r)
> 5eeec0ec9 Yinghai Lu     2009-12-22  249  {
> e906f1590 Baoquan He     2018-06-12  250  	struct resource *tmp, *next;
> 5eeec0ec9 Yinghai Lu     2009-12-22  251  	resource_size_t size;
> 5eeec0ec9 Yinghai Lu     2009-12-22  252
> e906f1590 Baoquan He     2018-06-12 @253  	list_for_each_entry_safe(tmp, next, &r->child, sibling) {
> 5eeec0ec9 Yinghai Lu     2009-12-22  254  		tmp->parent = NULL;
> e906f1590 Baoquan He     2018-06-12  255  		INIT_LIST_HEAD(&tmp->sibling);

							list_del_init(&tmp->sibling);

Thanks, Julia. Here I should use list_del_init(&op->list) to
replace INIT_LIST_HEAD(&tmp->sibling). 

> 5eeec0ec9 Yinghai Lu     2009-12-22  256  		__release_child_resources(tmp);
> 5eeec0ec9 Yinghai Lu     2009-12-22  257
> 5eeec0ec9 Yinghai Lu     2009-12-22  258  		printk(KERN_DEBUG "release child resource %pR\n", tmp);
> 5eeec0ec9 Yinghai Lu     2009-12-22  259  		/* need to restore size, and keep flags */
> 5eeec0ec9 Yinghai Lu     2009-12-22  260  		size = resource_size(tmp);
> 5eeec0ec9 Yinghai Lu     2009-12-22  261  		tmp->start = 0;
> 5eeec0ec9 Yinghai Lu     2009-12-22  262  		tmp->end = size - 1;
> 5eeec0ec9 Yinghai Lu     2009-12-22  263  	}
> e906f1590 Baoquan He     2018-06-12  264
> e906f1590 Baoquan He     2018-06-12 @265  	INIT_LIST_HEAD(&tmp->child);
> 5eeec0ec9 Yinghai Lu     2009-12-22  266  }
> 5eeec0ec9 Yinghai Lu     2009-12-22  267
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Oleksandr Andrushchenko @ 2018-06-13  6:43 UTC (permalink / raw)
  To: Juergen Gross, Oleksandr Andrushchenko, Dmitry Torokhov
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi
In-Reply-To: <e038df38-95be-b985-a2f8-2532f51736bd@suse.com>

On 06/13/2018 09:40 AM, Juergen Gross wrote:
> On 13/06/18 08:13, Oleksandr Andrushchenko wrote:
>> On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
>>> <andr2000@gmail.com> wrote:
>>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>
>>>>>>> This is the sync up with the canonical definitions of the input,
>>>>>>> sound and display protocols in Xen.
>>>>>>>
>>>>>>> Changes to kbdif:
>>>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>>>       to align with the rest of the interface file.
>>>>>>>
>>>>>>> 2. Add new XenStore feature fields, so it is possible to
>>>> individually
>>>>>>>       control set of exposed virtual devices for each guest OS:
>>>>>>>         - set feature-disable-keyboard to 1 if no keyboard device
>>>> needs
>>>>>>>           to be created
>>>>>>>         - set feature-disable-pointer to 1 if no pointer device needs
>>>>>>>           to be created
>>>>>>>
>>>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>>>        described as a part of frontend's XenBus configuration nodes
>>>>>>>        while they belong to backend's configuration. Fix this by
>>>> moving
>>>>>>>        the parameters to the proper section.
>>>>>>>
>>>>>>> Unique-id field:
>>>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>>>
>>>>>>> 2. Change type of unique-id field to string for sndif to align with
>>>>>>> display and input protocols.
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>> <oleksandr_andrushchenko@epam.com>
>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>>>>
>>>>>> I'm fine with this patch being added via the input tree with the
>>>> other
>>>>>> patches. In case I should take it via the Xen tree, please send me a
>>>>>> note.
>>>>> Juergen,
>>>>>
>>>>> I created an immutable branch off v4.17 with these 3 patches in case
>>>> you
>>>>> would want to merge them into your tree without waiting for them to
>>>>> appear in mainline:
>>>>>
>>>>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>>> ib/4.17-xen-kbdfront-runtime-config
>>>>> Thanks.
>>>>>
>>>> Thank you,
>>>> I would prefer the fastest path of course
>>> It will be part of 4.19 pull request; the immutable branch is for
>>> Juergen if he does not want to wait till 4.19 merge window to get the
>>> changes.
>> Ah, I see. Juergen, can we please merge this via Xen tree then which
>> I assume will be faster?
> As Dmitry has it already queued in the input tree I think this is fine.
> I trust him to take the right decision for which kernel version those
> patches are to be queued. They belong to the input tree after all.
Of course, no doubt here
>
> Juergen
>
Thank you,
Oleksandr

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Juergen Gross @ 2018-06-13  6:40 UTC (permalink / raw)
  To: Oleksandr Andrushchenko, Dmitry Torokhov
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <e1d62036-708d-5087-83f2-0ea32f3a6e74@gmail.com>

On 13/06/18 08:13, Oleksandr Andrushchenko wrote:
> On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
>> <andr2000@gmail.com> wrote:
>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>
>>>>>> This is the sync up with the canonical definitions of the input,
>>>>>> sound and display protocols in Xen.
>>>>>>
>>>>>> Changes to kbdif:
>>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>>      to align with the rest of the interface file.
>>>>>>
>>>>>> 2. Add new XenStore feature fields, so it is possible to
>>> individually
>>>>>>      control set of exposed virtual devices for each guest OS:
>>>>>>        - set feature-disable-keyboard to 1 if no keyboard device
>>> needs
>>>>>>          to be created
>>>>>>        - set feature-disable-pointer to 1 if no pointer device needs
>>>>>>          to be created
>>>>>>
>>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>>       described as a part of frontend's XenBus configuration nodes
>>>>>>       while they belong to backend's configuration. Fix this by
>>> moving
>>>>>>       the parameters to the proper section.
>>>>>>
>>>>>> Unique-id field:
>>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>>
>>>>>> 2. Change type of unique-id field to string for sndif to align with
>>>>>> display and input protocols.
>>>>>>
>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>> <oleksandr_andrushchenko@epam.com>
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>>>
>>>>> I'm fine with this patch being added via the input tree with the
>>> other
>>>>> patches. In case I should take it via the Xen tree, please send me a
>>>>> note.
>>>> Juergen,
>>>>
>>>> I created an immutable branch off v4.17 with these 3 patches in case
>>> you
>>>> would want to merge them into your tree without waiting for them to
>>>> appear in mainline:
>>>>
>>>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>> ib/4.17-xen-kbdfront-runtime-config
>>>> Thanks.
>>>>
>>> Thank you,
>>> I would prefer the fastest path of course
>> It will be part of 4.19 pull request; the immutable branch is for
>> Juergen if he does not want to wait till 4.19 merge window to get the
>> changes.
> Ah, I see. Juergen, can we please merge this via Xen tree then which
> I assume will be faster?

As Dmitry has it already queued in the input tree I think this is fine.
I trust him to take the right decision for which kernel version those
patches are to be queued. They belong to the input tree after all.


Juergen

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Oleksandr Andrushchenko @ 2018-06-13  6:28 UTC (permalink / raw)
  To: Dmitry Torokhov, Juergen Gross
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <800B1B3B-795F-4D0D-8B61-B66FC77A11A8@gmail.com>

On 06/13/2018 09:25 AM, Dmitry Torokhov wrote:
> On June 12, 2018 11:13:40 PM PDT, Oleksandr Andrushchenko <andr2000@gmail.com> wrote:
>> On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
>> <andr2000@gmail.com> wrote:
>>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>
>>>>>>> This is the sync up with the canonical definitions of the input,
>>>>>>> sound and display protocols in Xen.
>>>>>>>
>>>>>>> Changes to kbdif:
>>>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>>>       to align with the rest of the interface file.
>>>>>>>
>>>>>>> 2. Add new XenStore feature fields, so it is possible to
>>>> individually
>>>>>>>       control set of exposed virtual devices for each guest OS:
>>>>>>>         - set feature-disable-keyboard to 1 if no keyboard device
>>>> needs
>>>>>>>           to be created
>>>>>>>         - set feature-disable-pointer to 1 if no pointer device
>> needs
>>>>>>>           to be created
>>>>>>>
>>>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>>>        described as a part of frontend's XenBus configuration
>> nodes
>>>>>>>        while they belong to backend's configuration. Fix this by
>>>> moving
>>>>>>>        the parameters to the proper section.
>>>>>>>
>>>>>>> Unique-id field:
>>>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>>>
>>>>>>> 2. Change type of unique-id field to string for sndif to align
>> with
>>>>>>> display and input protocols.
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>> <oleksandr_andrushchenko@epam.com>
>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>>>>
>>>>>> I'm fine with this patch being added via the input tree with the
>>>> other
>>>>>> patches. In case I should take it via the Xen tree, please send me
>> a
>>>>>> note.
>>>>> Juergen,
>>>>>
>>>>> I created an immutable branch off v4.17 with these 3 patches in
>> case
>>>> you
>>>>> would want to merge them into your tree without waiting for them to
>>>>> appear in mainline:
>>>>>
>>>>> git pull
>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>>> ib/4.17-xen-kbdfront-runtime-config
>>>>> Thanks.
>>>>>
>>>> Thank you,
>>>> I would prefer the fastest path of course
>>> It will be part of 4.19 pull request; the immutable branch is for
>> Juergen if he does not want to wait till 4.19 merge window to get the
>> changes.
>> Ah, I see. Juergen, can we please merge this via Xen tree then which
>> I assume will be faster?
> We are in the tail end of 4.18 merge window so it should not make it in 4.18 no matter what tree the patches will go through.
Hm, but these are updates and fixes (besides the last patch which adds 
some more
functionality), so I thought this is still good to go in 4.18?
>
> Thanks.
>

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Dmitry Torokhov @ 2018-06-13  6:25 UTC (permalink / raw)
  To: Oleksandr Andrushchenko, Juergen Gross
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <e1d62036-708d-5087-83f2-0ea32f3a6e74@gmail.com>

On June 12, 2018 11:13:40 PM PDT, Oleksandr Andrushchenko <andr2000@gmail.com> wrote:
>On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
><andr2000@gmail.com> wrote:
>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>
>>>>>> This is the sync up with the canonical definitions of the input,
>>>>>> sound and display protocols in Xen.
>>>>>>
>>>>>> Changes to kbdif:
>>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>>      to align with the rest of the interface file.
>>>>>>
>>>>>> 2. Add new XenStore feature fields, so it is possible to
>>> individually
>>>>>>      control set of exposed virtual devices for each guest OS:
>>>>>>        - set feature-disable-keyboard to 1 if no keyboard device
>>> needs
>>>>>>          to be created
>>>>>>        - set feature-disable-pointer to 1 if no pointer device
>needs
>>>>>>          to be created
>>>>>>
>>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>>       described as a part of frontend's XenBus configuration
>nodes
>>>>>>       while they belong to backend's configuration. Fix this by
>>> moving
>>>>>>       the parameters to the proper section.
>>>>>>
>>>>>> Unique-id field:
>>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>>
>>>>>> 2. Change type of unique-id field to string for sndif to align
>with
>>>>>> display and input protocols.
>>>>>>
>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>> <oleksandr_andrushchenko@epam.com>
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>>>
>>>>> I'm fine with this patch being added via the input tree with the
>>> other
>>>>> patches. In case I should take it via the Xen tree, please send me
>a
>>>>> note.
>>>> Juergen,
>>>>
>>>> I created an immutable branch off v4.17 with these 3 patches in
>case
>>> you
>>>> would want to merge them into your tree without waiting for them to
>>>> appear in mainline:
>>>>
>>>> git pull
>git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>> ib/4.17-xen-kbdfront-runtime-config
>>>> Thanks.
>>>>
>>> Thank you,
>>> I would prefer the fastest path of course
>> It will be part of 4.19 pull request; the immutable branch is for
>Juergen if he does not want to wait till 4.19 merge window to get the
>changes.
>Ah, I see. Juergen, can we please merge this via Xen tree then which
>I assume will be faster?

We are in the tail end of 4.18 merge window so it should not make it in 4.18 no matter what tree the patches will go through.


Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Oleksandr Andrushchenko @ 2018-06-13  6:13 UTC (permalink / raw)
  To: Dmitry Torokhov, Juergen Gross
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <D53587A2-5B1B-4D8F-8772-04D453B93D38@gmail.com>

On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko <andr2000@gmail.com> wrote:
>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> This is the sync up with the canonical definitions of the input,
>>>>> sound and display protocols in Xen.
>>>>>
>>>>> Changes to kbdif:
>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>      to align with the rest of the interface file.
>>>>>
>>>>> 2. Add new XenStore feature fields, so it is possible to
>> individually
>>>>>      control set of exposed virtual devices for each guest OS:
>>>>>        - set feature-disable-keyboard to 1 if no keyboard device
>> needs
>>>>>          to be created
>>>>>        - set feature-disable-pointer to 1 if no pointer device needs
>>>>>          to be created
>>>>>
>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>       described as a part of frontend's XenBus configuration nodes
>>>>>       while they belong to backend's configuration. Fix this by
>> moving
>>>>>       the parameters to the proper section.
>>>>>
>>>>> Unique-id field:
>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>
>>>>> 2. Change type of unique-id field to string for sndif to align with
>>>>> display and input protocols.
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko
>> <oleksandr_andrushchenko@epam.com>
>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>>
>>>> I'm fine with this patch being added via the input tree with the
>> other
>>>> patches. In case I should take it via the Xen tree, please send me a
>>>> note.
>>> Juergen,
>>>
>>> I created an immutable branch off v4.17 with these 3 patches in case
>> you
>>> would want to merge them into your tree without waiting for them to
>>> appear in mainline:
>>>
>>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>> ib/4.17-xen-kbdfront-runtime-config
>>> Thanks.
>>>
>> Thank you,
>> I would prefer the fastest path of course
> It will be part of 4.19 pull request; the immutable branch is for Juergen if he does not want to wait till 4.19 merge window to get the changes.
Ah, I see. Juergen, can we please merge this via Xen tree then which
I assume will be faster?
>
> Thanks.
>
Thank you,
Oleksandr

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Dmitry Torokhov @ 2018-06-13  6:11 UTC (permalink / raw)
  To: Oleksandr Andrushchenko, Juergen Gross
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <3605901d-4a72-3f5a-6d74-cb13d2414a0b@gmail.com>

On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko <andr2000@gmail.com> wrote:
>On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> This is the sync up with the canonical definitions of the input,
>>>> sound and display protocols in Xen.
>>>>
>>>> Changes to kbdif:
>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>     to align with the rest of the interface file.
>>>>
>>>> 2. Add new XenStore feature fields, so it is possible to
>individually
>>>>     control set of exposed virtual devices for each guest OS:
>>>>       - set feature-disable-keyboard to 1 if no keyboard device
>needs
>>>>         to be created
>>>>       - set feature-disable-pointer to 1 if no pointer device needs
>>>>         to be created
>>>>
>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>      described as a part of frontend's XenBus configuration nodes
>>>>      while they belong to backend's configuration. Fix this by
>moving
>>>>      the parameters to the proper section.
>>>>
>>>> Unique-id field:
>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>
>>>> 2. Change type of unique-id field to string for sndif to align with
>>>> display and input protocols.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko
><oleksandr_andrushchenko@epam.com>
>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>
>>> I'm fine with this patch being added via the input tree with the
>other
>>> patches. In case I should take it via the Xen tree, please send me a
>>> note.
>> Juergen,
>>
>> I created an immutable branch off v4.17 with these 3 patches in case
>you
>> would want to merge them into your tree without waiting for them to
>> appear in mainline:
>>
>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>ib/4.17-xen-kbdfront-runtime-config
>>
>> Thanks.
>>
>Thank you,
>I would prefer the fastest path of course

It will be part of 4.19 pull request; the immutable branch is for Juergen if he does not want to wait till 4.19 merge window to get the changes.


Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Oleksandr Andrushchenko @ 2018-06-13  5:49 UTC (permalink / raw)
  To: Dmitry Torokhov, Juergen Gross
  Cc: xen-devel, linux-input, linux-kernel, lyan, boris.ostrovsky,
	konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <20180612234020.GI38773@dtor-ws>

On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> This is the sync up with the canonical definitions of the input,
>>> sound and display protocols in Xen.
>>>
>>> Changes to kbdif:
>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>     to align with the rest of the interface file.
>>>
>>> 2. Add new XenStore feature fields, so it is possible to individually
>>>     control set of exposed virtual devices for each guest OS:
>>>       - set feature-disable-keyboard to 1 if no keyboard device needs
>>>         to be created
>>>       - set feature-disable-pointer to 1 if no pointer device needs
>>>         to be created
>>>
>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>      described as a part of frontend's XenBus configuration nodes
>>>      while they belong to backend's configuration. Fix this by moving
>>>      the parameters to the proper section.
>>>
>>> Unique-id field:
>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>
>>> 2. Change type of unique-id field to string for sndif to align with
>>> display and input protocols.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>
>> I'm fine with this patch being added via the input tree with the other
>> patches. In case I should take it via the Xen tree, please send me a
>> note.
> Juergen,
>
> I created an immutable branch off v4.17 with these 3 patches in case you
> would want to merge them into your tree without waiting for them to
> appear in mainline:
>
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/4.17-xen-kbdfront-runtime-config
>
> Thanks.
>
Thank you,
I would prefer the fastest path of course

^ permalink raw reply

* Re: [PATCH v5 3/3] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-06-13  5:47 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
	boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
	Oleksandr Andrushchenko
In-Reply-To: <20180612220722.GA38773@dtor-ws>

On 06/13/2018 01:07 AM, Dmitry Torokhov wrote:
> On Tue, Jun 12, 2018 at 10:48:56AM +0300, Oleksandr Andrushchenko wrote:
>>   
>> +	if (!(with_kbd | with_ptr | with_mtouch)) {
> I changed this to logical "OR" and applied, thank you.
Yes, that's better, thank you
>> +		ret = -ENXIO;
>> +		goto error;
>> +	}
>> +
>>   	ret = xenkbd_connect_backend(dev, info);
>>   	if (ret < 0)
>>   		goto error;
>> -- 
>> 2.17.1
>>

^ permalink raw reply

* Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Tony Lindgren @ 2018-06-13  4:41 UTC (permalink / raw)
  To: Janusz Krzysztofik
  Cc: Dmitry Torokhov, linux-omap, Aaro Koskinen, David S . Miller,
	Mauro Carvalho Chehab, Greg Kroah-Hartman, Andrew Morton,
	Randy Dunlap, Liam Girdwood, Mark Brown, Linus Walleij,
	linux-arm-kernel, linux-input, linux-gpio, linux-kernel
In-Reply-To: <69494657.T0PeNZxiFJ@z50>

* Janusz Krzysztofik <jmkrzyszt@gmail.com> [180613 01:18]:
> On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > Hi Janusz,
> > 
> > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > lookup table" was not accepted by subystem maintainer who requested
> > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > with a regulator and removal of remaining GPIO pins from the driver as
> > > not handled by it.
> > > 
> > > Let's start with removal of no the longer needed GPIO lookup table from
> > > the board init file.
> > > 
> > > Series created and tested on top of next-20180608 tag from linux-next
> > > tree.
> > 
> > This all is really nice (modulo a couple of questions), thank you for
> > implementing this. How do you want to merge this? Through OMAP tree or
> > input?
> 
> Hi Dmitry,
> 
> If Tony doesn't mind, I would prefer it merged through OMAP tree as I still 
> have a few board patches built on top of it in my queue.

Works for me once Dmitry is happy with the patches.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Janusz Krzysztofik @ 2018-06-13  1:16 UTC (permalink / raw)
  To: Dmitry Torokhov, linux-omap
  Cc: Tony Lindgren, Aaro Koskinen, David S . Miller,
	Mauro Carvalho Chehab, Greg Kroah-Hartman, Andrew Morton,
	Randy Dunlap, Liam Girdwood, Mark Brown, Linus Walleij,
	linux-arm-kernel, linux-input, linux-gpio, linux-kernel
In-Reply-To: <20180612222356.GD38773@dtor-ws>

On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> Hi Janusz,
> 
> On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > GPIO lookup table for ams-delta-serio device was introduced by commit
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > lookup table" was not accepted by subystem maintainer who requested
> > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > with a regulator and removal of remaining GPIO pins from the driver as
> > not handled by it.
> > 
> > Let's start with removal of no the longer needed GPIO lookup table from
> > the board init file.
> > 
> > Series created and tested on top of next-20180608 tag from linux-next
> > tree.
> 
> This all is really nice (modulo a couple of questions), thank you for
> implementing this. How do you want to merge this? Through OMAP tree or
> input?

Hi Dmitry,

If Tony doesn't mind, I would prefer it merged through OMAP tree as I still 
have a few board patches built on top of it in my queue.

Thanks,
Janusz

^ permalink raw reply

* Re: [PATCH 09/10] Input: ams_delta_serio: use IRQ resource
From: Janusz Krzysztofik @ 2018-06-13  1:10 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Tony Lindgren, Aaro Koskinen, David S . Miller,
	Mauro Carvalho Chehab, Greg Kroah-Hartman, Andrew Morton,
	Randy Dunlap, Liam Girdwood, Mark Brown, Linus Walleij,
	linux-arm-kernel, linux-input, linux-omap, linux-gpio,
	linux-kernel, Janusz Krzysztofik
In-Reply-To: <20180612222104.GC38773@dtor-ws>

On Wednesday, June 13, 2018 12:21:04 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> > ...
> > @@ -141,14 +141,11 @@ static int ams_delta_serio_init(struct
> > platform_device *pdev)> 
> >  	 * at FIQ level, switch back from edge to simple interrupt handler
> >  	 * to avoid bad interaction.
> >  	 */
> > 
> > -	irq_set_handler(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> > -			handle_simple_irq);
> > +	irq_set_handler(irq, handle_simple_irq);
> 
> Do we still need to do this here, or it can be moved into board file?

You're right, it should be possible to move it. I'll check possible options 
and submit a follow up patch.

Thanks,
Janusz

^ permalink raw reply

* Re: [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Janusz Krzysztofik @ 2018-06-13  1:01 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Tony Lindgren, Aaro Koskinen, David S . Miller,
	Mauro Carvalho Chehab, Greg Kroah-Hartman, Andrew Morton,
	Randy Dunlap, Liam Girdwood, Mark Brown, Linus Walleij,
	linux-arm-kernel, linux-input, linux-omap, linux-gpio,
	linux-kernel, Janusz Krzysztofik
In-Reply-To: <20180612221724.GB38773@dtor-ws>

On Wednesday, June 13, 2018 12:17:24 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> > ...
> > +	priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > +	if (IS_ERR(priv->vcc)) {
> > +		err = PTR_ERR(priv->vcc);
> > +		dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> > +		/* Fail softly if the regulator is not available yet */
> > +		if (err == -ENODEV)
> > +			err = -EPROBE_DEFER;
> 
> Hmm, if regulator is not ready yet, devm_regulator_get() should be
> returning -EPROBE_DEFER already, we should not have to convert -ENODEV
> to -EPROBE_DEFER...

Regulator is not ready because its initialization at subsys_initcall is 
deferred by not ready GPIO pin, that in turn is caused by gpio-mmio driver, 
unlike many other GPIO drivers, registered as late as at device_initcall.

I agree devm_regulator_get() could return -EPROBE_DEFER in this case, but I 
can see it does that only when of_get_regulator() indicates the regulator 
should exist. In non-dt case there is apparently no way to justify if it 
should unless its consumer supply table was already in place. For that,  
registration of that table would have to be independent of successful 
registration of the regulator itself while it's not. Maybe it should, but 
that's a separate topic for a separate discussion, I think.

> Is it because we have_full_constraints() returns false? You might need
> to add call to regulator_has_full_constraints() to your board file.

If have_full_constraints() returned true before the regulator or its consumer 
supply table is ready, devm_regulator_get() would happily return a dummy 
regulator and our keyboard would never get its power.

I'm afraid we have to live with that return code conversion as long as the 
only user of this driver is not migrated to dt.

Thanks,
Janusz

^ permalink raw reply

* Re: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Srinivas Pandruvada @ 2018-06-13  0:14 UTC (permalink / raw)
  To: Xu, Even, Jiri Kosina
  Cc: benjamin.tissoires@redhat.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <9577C59DB499174B9340876B077C2E9569DF11EC@SHSMSX101.ccr.corp.intel.com>

On Wed, 2018-06-13 at 00:05 +0000, Xu, Even wrote:
> Ok, sure, I will update patch comments and resubmit.
Can you also add in the sign-off area


Cc: stable@vger.kernel.org

Thanks,
Srinivas

> Thanks Srinivas!
> 
> Best Regards,
> Even Xu
> 
> 
> 
> -----Original Message-----
> From: Srinivas Pandruvada [mailto:srinivas.pandruvada@linux.intel.com
> ] 
> Sent: Tuesday, June 12, 2018 11:31 PM
> To: Jiri Kosina <jikos@kernel.org>; Xu, Even <even.xu@intel.com>
> Cc: benjamin.tissoires@redhat.com; linux-input@vger.kernel.org; linux
> -kernel@vger.kernel.org; Xu, Even <even.xu@intel.com>
> Subject: Re: [PATCH] hid: intel_ish-hid: ipc: register more pm
> callbacks to support hibernation
> 
> On Tue, 2018-06-12 at 16:53 +0200, Jiri Kosina wrote:
> > On Sun, 10 Jun 2018, Srinivas Pandruvada wrote:
> > 
> > > From: Even Xu <even.xu@intel.com>
> > > 
> > > Current ish driver only register resume/suspend PM callbacks
> > > which 
> > > don't support hibernation (suspend to disk). Now use the
> > > SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
> > > The suspend and resume functions will now be used for both
> > > suspend 
> > > to RAM and hibernation.
> > > 
> > > If power management is disable, SIMPLE_DEV_PM_OPS will do
> > > nothing, 
> > > the suspend and resume related functions won't be used, so mark
> > > them 
> > > as __maybe_unused to clarify that this is intended behavior, and 
> > > remove #ifdefs for power management.
> > 
> > This describes details the patch does on code level, but what are
> > the 
> > user observable effects? Hibernation resume doesn't fail any more?
> > Hibernation
> > is possible (and wasn't before)? Did kernel crash while trying to 
> > hibernate and this is the fix? Or ... ?
> 
> Even,
> Can you add more details and resubmit ASAP?
> 
> Basically after hiberation, the ISH can't resume properly and user
> may not see sensor events (for example: screen rotation may not
> work).
> User will not see a crash or panic or anything except the following
> message in log:
> hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from
> ISHTP device 
> 
> So this is adding support for S4/hiberbation to ISH.
> 
> 
> 
> Thanks,
> Srinivas
> 
> > 
> > Thanks,
> > 

^ permalink raw reply

* RE: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Xu, Even @ 2018-06-13  0:05 UTC (permalink / raw)
  To: Srinivas Pandruvada, Jiri Kosina
  Cc: benjamin.tissoires@redhat.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <634cd945beca786dc77876f71e39459cef6fbd75.camel@linux.intel.com>

Ok, sure, I will update patch comments and resubmit.
Thanks Srinivas!

Best Regards,
Even Xu



-----Original Message-----
From: Srinivas Pandruvada [mailto:srinivas.pandruvada@linux.intel.com] 
Sent: Tuesday, June 12, 2018 11:31 PM
To: Jiri Kosina <jikos@kernel.org>; Xu, Even <even.xu@intel.com>
Cc: benjamin.tissoires@redhat.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; Xu, Even <even.xu@intel.com>
Subject: Re: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation

On Tue, 2018-06-12 at 16:53 +0200, Jiri Kosina wrote:
> On Sun, 10 Jun 2018, Srinivas Pandruvada wrote:
> 
> > From: Even Xu <even.xu@intel.com>
> > 
> > Current ish driver only register resume/suspend PM callbacks which 
> > don't support hibernation (suspend to disk). Now use the
> > SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
> > The suspend and resume functions will now be used for both suspend 
> > to RAM and hibernation.
> > 
> > If power management is disable, SIMPLE_DEV_PM_OPS will do nothing, 
> > the suspend and resume related functions won't be used, so mark them 
> > as __maybe_unused to clarify that this is intended behavior, and 
> > remove #ifdefs for power management.
> 
> This describes details the patch does on code level, but what are the 
> user observable effects? Hibernation resume doesn't fail any more?
> Hibernation
> is possible (and wasn't before)? Did kernel crash while trying to 
> hibernate and this is the fix? Or ... ?
Even,
Can you add more details and resubmit ASAP?

Basically after hiberation, the ISH can't resume properly and user may not see sensor events (for example: screen rotation may not work).
User will not see a crash or panic or anything except the following message in log:
hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP device 

So this is adding support for S4/hiberbation to ISH.



Thanks,
Srinivas

> 
> Thanks,
> 

^ permalink raw reply

* RE: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Xu, Even @ 2018-06-13  0:04 UTC (permalink / raw)
  To: Jiri Kosina, Srinivas Pandruvada
  Cc: benjamin.tissoires@redhat.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <nycvar.YFH.7.76.1806121651460.6203@cbobk.fhfr.pm>

Hi, Jiri Kosina,

If without this patch, the platform with ISH, its hibernation resume will take more than 10s because of ISH resume failure, it will also cause ISH not functional.
With this patch, everything will go will.

Best Regards,
Even Xu


-----Original Message-----
From: Jiri Kosina [mailto:jikos@kernel.org] 
Sent: Tuesday, June 12, 2018 10:53 PM
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: benjamin.tissoires@redhat.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; Xu, Even <even.xu@intel.com>
Subject: Re: [PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation

On Sun, 10 Jun 2018, Srinivas Pandruvada wrote:

> From: Even Xu <even.xu@intel.com>
> 
> Current ish driver only register resume/suspend PM callbacks which 
> don't support hibernation (suspend to disk). Now use the
> SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
> The suspend and resume functions will now be used for both suspend to 
> RAM and hibernation.
> 
> If power management is disable, SIMPLE_DEV_PM_OPS will do nothing, the 
> suspend and resume related functions won't be used, so mark them as 
> __maybe_unused to clarify that this is intended behavior, and remove 
> #ifdefs for power management.

This describes details the patch does on code level, but what are the user observable effects? Hibernation resume doesn't fail any more? Hibernation is possible (and wasn't before)? Did kernel crash while trying to hibernate and this is the fix? Or ... ?

Thanks,

--
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen
From: Dmitry Torokhov @ 2018-06-12 23:40 UTC (permalink / raw)
  To: Juergen Gross
  Cc: Oleksandr Andrushchenko, xen-devel, linux-input, linux-kernel,
	lyan, boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
	Oleksandr Andrushchenko
In-Reply-To: <9c579567-ebe2-f465-5443-b3a3e71d34a5@suse.com>

On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > 
> > This is the sync up with the canonical definitions of the input,
> > sound and display protocols in Xen.
> > 
> > Changes to kbdif:
> > 1. Add missing string constants for {feature|request}-raw-pointer
> >    to align with the rest of the interface file.
> > 
> > 2. Add new XenStore feature fields, so it is possible to individually
> >    control set of exposed virtual devices for each guest OS:
> >      - set feature-disable-keyboard to 1 if no keyboard device needs
> >        to be created
> >      - set feature-disable-pointer to 1 if no pointer device needs
> >        to be created
> > 
> > 3. Move multi-touch device parameters to backend nodes: these are
> >     described as a part of frontend's XenBus configuration nodes
> >     while they belong to backend's configuration. Fix this by moving
> >     the parameters to the proper section.
> > 
> > Unique-id field:
> > 1. Add unique-id XenBus entry for virtual input and display.
> > 
> > 2. Change type of unique-id field to string for sndif to align with
> > display and input protocols.
> > 
> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>
> 
> I'm fine with this patch being added via the input tree with the other
> patches. In case I should take it via the Xen tree, please send me a
> note.

Juergen,

I created an immutable branch off v4.17 with these 3 patches in case you
would want to merge them into your tree without waiting for them to
appear in mainline:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git ib/4.17-xen-kbdfront-runtime-config

Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH V3] i8042: Increment wakeup_count for the respective port.
From: Dmitry Torokhov @ 2018-06-12 23:33 UTC (permalink / raw)
  To: Ravi Chandra Sadineni
  Cc: rafael, chenhong3, ravisadineni, linux-kernel, linux-input,
	rajatja, bleung, furquan
In-Reply-To: <20180605190124.191827-1-ravisadineni@chromium.org>

On Tue, Jun 05, 2018 at 12:01:24PM -0700, Ravi Chandra Sadineni wrote:
> Call pm_wakeup_event on every irq. This should help us in identifying if
> keyboard was a potential wake reason for the last resume.
> 
> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>

Applied, thank you.

> ---
> V3: Remove the unnecessary device_may_wakeup check.
> V2: Increment the wakeup count only when there is a irq and not when the
> method is called internally.
> 
>  drivers/input/serio/i8042.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index 824f4c1c1f310..b8bc71569349d 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -573,6 +573,9 @@ static irqreturn_t i8042_interrupt(int irq, void *dev_id)
>  	port = &i8042_ports[port_no];
>  	serio = port->exists ? port->serio : NULL;
>  
> +	if (irq && serio)
> +		pm_wakeup_event(&serio->dev, 0);
> +
>  	filter_dbg(port->driver_bound, data, "<- i8042 (interrupt, %d, %d%s%s)\n",
>  		   port_no, irq,
>  		   dfl & SERIO_PARITY ? ", bad parity" : "",
> -- 
> 2.17.1.1185.g55be947832-goog
> 

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.
From: Dmitry Torokhov @ 2018-06-12 23:32 UTC (permalink / raw)
  To: Ravi Chandra Sadineni
  Cc: ravisadineni, dtor, tbroch, linux-kernel, linux-input
In-Reply-To: <20180605224458.62692-1-ravisadineni@chromium.org>

On Tue, Jun 05, 2018 at 03:44:57PM -0700, Ravi Chandra Sadineni wrote:
> Remove the unnecessary check before calling pm_wakeup_event. If the
> device is not wake enabled, this call is no-op anyway.
> 
> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>

Applied, thank you.

> ---
>  drivers/input/keyboard/cros_ec_keyb.c | 30 ++++++++++-----------------
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 489ddd37bd4ee..c5e32544130dc 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -242,19 +242,17 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
>  	u32 val;
>  	unsigned int ev_type;
>  
> +	/*
> +	 * If not wake enabled, discard key state changes during
> +	 * suspend. Switches will be re-checked in
> +	 * cros_ec_keyb_resume() to be sure nothing is lost.
> +	 */
> +	if (queued_during_suspend && !device_may_wakeup(ckdev->dev))
> +		return NOTIFY_OK;
> +
>  	switch (ckdev->ec->event_data.event_type) {
>  	case EC_MKBP_EVENT_KEY_MATRIX:
> -		if (device_may_wakeup(ckdev->dev)) {
> -			pm_wakeup_event(ckdev->dev, 0);
> -		} else {
> -			/*
> -			 * If keyboard is not wake enabled, discard key state
> -			 * changes during suspend. Switches will be re-checked
> -			 * in cros_ec_keyb_resume() to be sure nothing is lost.
> -			 */
> -			if (queued_during_suspend)
> -				return NOTIFY_OK;
> -		}
> +		pm_wakeup_event(ckdev->dev, 0);
>  
>  		if (ckdev->ec->event_size != ckdev->cols) {
>  			dev_err(ckdev->dev,
> @@ -268,10 +266,7 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
>  		break;
>  
>  	case EC_MKBP_EVENT_SYSRQ:
> -		if (device_may_wakeup(ckdev->dev))
> -			pm_wakeup_event(ckdev->dev, 0);
> -		else if (queued_during_suspend)
> -			return NOTIFY_OK;
> +		pm_wakeup_event(ckdev->dev, 0);
>  
>  		val = get_unaligned_le32(&ckdev->ec->event_data.data.sysrq);
>  		dev_dbg(ckdev->dev, "sysrq code from EC: %#x\n", val);
> @@ -280,10 +275,7 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
>  
>  	case EC_MKBP_EVENT_BUTTON:
>  	case EC_MKBP_EVENT_SWITCH:
> -		if (device_may_wakeup(ckdev->dev))
> -			pm_wakeup_event(ckdev->dev, 0);
> -		else if (queued_during_suspend)
> -			return NOTIFY_OK;
> +		pm_wakeup_event(ckdev->dev, 0);
>  
>  		if (ckdev->ec->event_data.event_type == EC_MKBP_EVENT_BUTTON) {
>  			val = get_unaligned_le32(
> -- 
> 2.18.0.rc1.242.g61856ae69a-goog
> 

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH v3 10/12] Input: cros_ec_keyb - Switch to SPDX identifier.
From: Dmitry Torokhov @ 2018-06-12 23:30 UTC (permalink / raw)
  To: Enric Balletbo i Serra; +Cc: linux-kernel, Gwendal Grignou, kernel, linux-input
In-Reply-To: <20180606150900.8342-11-enric.balletbo@collabora.com>

On Wed, Jun 06, 2018 at 05:08:58PM +0200, Enric Balletbo i Serra wrote:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

Applied, thank you.

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/input/keyboard/cros_ec_keyb.c | 34 ++++++++++-----------------
>  1 file changed, 12 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 9dd8c146699f..dd1b356d0004 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -1,25 +1,15 @@
> -/*
> - * ChromeOS EC keyboard driver
> - *
> - * Copyright (C) 2012 Google, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This driver uses the Chrome OS EC byte-level message-based protocol for
> - * communicating the keyboard state (which keys are pressed) from a keyboard EC
> - * to the AP over some bus (such as i2c, lpc, spi).  The EC does debouncing,
> - * but everything else (including deghosting) is done here.  The main
> - * motivation for this is to keep the EC firmware as simple as possible, since
> - * it cannot be easily upgraded and EC flash/IRAM space is relatively
> - * expensive.
> - */
> +// SPDX-License-Identifier: GPL-2.0
> +// ChromeOS EC keyboard driver
> +//
> +// Copyright (C) 2012 Google, Inc.
> +//
> +// This driver uses the ChromeOS EC byte-level message-based protocol for
> +// communicating the keyboard state (which keys are pressed) from a keyboard EC
> +// to the AP over some bus (such as i2c, lpc, spi).  The EC does debouncing,
> +// but everything else (including deghosting) is done here.  The main
> +// motivation for this is to keep the EC firmware as simple as possible, since
> +// it cannot be easily upgraded and EC flash/IRAM space is relatively
> +// expensive.
>  
>  #include <linux/module.h>
>  #include <linux/bitops.h>
> -- 
> 2.17.1
> 

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH v3 09/12] Input: cros_ec_keyb - Make license text and module license match.
From: Dmitry Torokhov @ 2018-06-12 23:30 UTC (permalink / raw)
  To: Enric Balletbo i Serra; +Cc: linux-kernel, Gwendal Grignou, kernel, linux-input
In-Reply-To: <20180606150900.8342-10-enric.balletbo@collabora.com>

On Wed, Jun 06, 2018 at 05:08:57PM +0200, Enric Balletbo i Serra wrote:
> The license text is specifying "GPLv2" but the MODULE_LICENSE is set to
> GPL which means GNU Public License v2 or later. When MODULE_LICENSE and
> boiler plate does not match, go for boiler plate license.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

Applied, thank you.

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/input/keyboard/cros_ec_keyb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index 79eb29550c34..9dd8c146699f 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -674,6 +674,6 @@ static struct platform_driver cros_ec_keyb_driver = {
>  
>  module_platform_driver(cros_ec_keyb_driver);
>  
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("ChromeOS EC keyboard driver");
>  MODULE_ALIAS("platform:cros-ec-keyb");
> -- 
> 2.17.1
> 

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Dmitry Torokhov @ 2018-06-12 22:23 UTC (permalink / raw)
  To: Janusz Krzysztofik
  Cc: Tony Lindgren, Aaro Koskinen, David S . Miller,
	Mauro Carvalho Chehab, Greg Kroah-Hartman, Andrew Morton,
	Randy Dunlap, Liam Girdwood, Mark Brown, Linus Walleij,
	linux-arm-kernel, linux-input, linux-omap, linux-gpio,
	linux-kernel
In-Reply-To: <20180609140224.32606-1-jmkrzyszt@gmail.com>

Hi Janusz,

On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> GPIO lookup table for ams-delta-serio device was introduced by commit
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> lookup table" was not accepted by subystem maintainer who requested
> conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> pin with IRQ resource, replacement of GPIO pin providing keyboard power
> with a regulator and removal of remaining GPIO pins from the driver as
> not handled by it.
> 
> Let's start with removal of no the longer needed GPIO lookup table from
> the board init file.
> 
> Series created and tested on top of next-20180608 tag from linux-next
> tree.

This all is really nice (modulo a couple of questions), thank you for
implementing this. How do you want to merge this? Through OMAP tree or
input?

> 
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c | 19 -------------------
>  1 file changed, 19 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 80f54cb54276..18e0ff437b27 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -504,20 +504,6 @@ static struct platform_device cx20442_codec_device = {
>  	.id     = -1,
>  };
>  
> -static struct gpiod_lookup_table ams_delta_serio_gpio_table = {
> -	.table = {
> -		GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
> -			    "data", 0),
> -		GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
> -			    "clock", 0),
> -		GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_PWR,
> -			    "power", 0),
> -		GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_DATAOUT,
> -			    "dataout", 0),
> -		{ },
> -	},
> -};
> -
>  static struct platform_device *ams_delta_devices[] __initdata = {
>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
> @@ -534,7 +520,6 @@ static struct platform_device *late_devices[] __initdata = {
>  
>  static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = {
>  	&ams_delta_audio_gpio_table,
> -	&ams_delta_serio_gpio_table,
>  };
>  
>  static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> @@ -580,10 +565,6 @@ static void __init ams_delta_init(void)
>  	 */
>  	ams_delta_audio_gpio_table.dev_id =
>  			dev_name(&ams_delta_audio_device.dev);
> -	/*
> -	 * No device name is assigned to GPIO lookup table for serio device
> -	 * as long as serio driver is not converted to platform device driver.
> -	 */
>  
>  	gpiod_add_lookup_tables(ams_delta_gpio_tables,
>  				ARRAY_SIZE(ams_delta_gpio_tables));
> -- 
> 2.16.1
> 

-- 
Dmitry

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox