* Re: [PATCH v3 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation
From: Baolin Wang @ 2018-04-30 8:06 UTC (permalink / raw)
To: Rob Herring
Cc: Dmitry Torokhov, Mark Rutland, Orson Zhai, Chunyan Zhang,
open list:HID CORE LAYER, DTML, LKML, xiaotong.lu
In-Reply-To: <20180427145116.rhjs5vqg6czdexee@rob-hp-laptop>
Hi Rob,
On 27 April 2018 at 22:51, Rob Herring <robh@kernel.org> wrote:
> On Thu, Apr 26, 2018 at 05:12:33PM +0800, Baolin Wang wrote:
>> From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
>>
>> This patch adds the binding documentation for Spreadtrum SC27xx series
>> vibrator device.
>>
>> Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>> ---
>> Changes since v2:
>> - No updates.
>>
>> Changes since v1:
>> - No updates.
>> ---
>> .../bindings/input/sprd,sc27xx-vibra.txt | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>>
>> diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>> new file mode 100644
>> index 0000000..92ead29
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>> @@ -0,0 +1,12 @@
>> +Spreadtrum SC27xx PMIC Vibrator
>> +
>> +Required properties:
>> +- compatible: should be "sprd,sc27xx-vibrator".
>> +- reg: address of vibrator control register.
>> +
>> +Example :
>> +
>> +vibrator@eb4 {
>> + compatible = "sprd,sc27xx-vibrator";
>> + reg = <0xeb4>;
>
> What bus is this on? A mmio bus needs a length. Is this part of some
> other block?
>
It's on one PMIC bus mapped by regmap-spi. Will add the PMIC part in
next version:
sc2731_pmic: pmic@0 {
compatible = "sprd,sc2731";
reg = <0>;
spi-max-frequency = <26000000>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <2>;
#address-cells = <1>;
#size-cells = <0>;
vibrator@eb4 {
compatible = "sprd,sc27xx-vibrator";
reg = <0xeb4>;
};
};
Is that OK for you? Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.
From: Vittorio Gambaletta (VittGam) @ 2018-04-29 23:44 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: mrchromebox, linux-kernel, linux-input, # v4 . 10+, nick,
Benson Leung, Salvatore Bellizzi, Guenter Roeck, Guenter Roeck
In-Reply-To: <20180426164218.GA162443@dtor-ws>
Hello,
On 26/04/2018 18:42:18 CEST, Dmitry Torokhov wrote:
> On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote:
>> On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) <
>> linuxbugs@vittgam.net> wrote:
>>
>> > Hello,
>> >
>> > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote:
>> > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote:
>> > >> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam)
>> > wrote:
>> > >> > This patch adds the correct platform data information for the Caroline
>> > >> > Chromebook, so that the mouse button does not get stuck in pressed
>> > state
>> > >> > after the first click.
>> > >> >
>> > >> > The Samus button keymap and platform data definition are the correct
>> > >> > ones for Caroline, so they have been reused here.
>> > >> >
>> > >> > v2: updated patch offset after 20180409 changes.
>> > >> >
>> > >> > Cc: stable@vger.kernel.org
>> > >> > Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>> > >> > Signed-off-by: Salvatore Bellizzi <lkml@seppia.net>
>> > >> >
>> > >>
>> > >> Applied, thank you.
>> > >>
>> > >> > ---
>> > >> >
>> > >> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
>> > >> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>> > >> > @@ -3035,6 +3035,15 @@
>> > >> > .driver_data = samus_platform_data,
>> > >> > },
>> > >> > {
>> > >> > + /* Samsung Chromebook Pro */
>> > >> > + .ident = "Samsung Chromebook Pro",
>> > >> > + .matches = {
>> > >> > + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
>> > >
>> > > I've been alerted that shipping BIOS has vendor not capitalized; where
>> > > did you get the firmware that has vendor all capitals?
>> >
>> > Upstream coreboot and mrchromebox's coreboot, which do support loading
>> > Linux
>> > natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor
>> > as far as I know.
>> >
>> > By the way, the shipping BIOS (coreboot customized by Google) does not
>> > support
>> > mainline Linux natively (eg. without seabios and nasty tricks), but only
>> > Chromium OS, which for Caroline is an old 3.something fork of Linux, so
>> > this
>> > patch does not really apply to Chromium OS or to Linux running on shipping
>> > BIOS.
>> >
>> Can you provide details or a pointer to it ? The mainline kernel boots
>> fine for me (with a ChromeOS distribution), with the exception of the
>> Google/GOOGLE problem.
Hmmm, did you change the kernel on your ChromeOS system, or did Google update it?
My Chromebook was on 3.18 when I was still having stock Google Chrome OS on it.
This should be the relevant tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/release-R58-9334.B-caroline-chromeos-3.18
>> > Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in
>> > Google's coreboot for Caroline too, but I'm not 100% sure and cannot check
>> > right now.
>> >
>> >
>> FWIW, the DMI system vendor is "Google" in my Caroline. I'll dig up
>> configuration files later today - maybe it was changed to "GOOGLE" at some
>> point and I have an old Bios in my system.
>
> I believe all shipping BIOSes use "Google" as vendor, as it is what is
> specified in src/mainboard/google/Kconfig::MAINBOARD_VENDOR and our
> configs/build scripts do not override it.
>
> I do not know why we have this difference.
Okay, so first of all sorry for the confusion.
The upstream coreboot still does not have Caroline support as far as I can tell.
Instead, I'm using coreboot by Matt aka Mr. Chromebox, who is working towards
upstreaming all of Google Skylake boards, such as Caroline, into coreboot.
His default configs were overriding the CONFIG_MAINBOARD_SMBIOS_MANUFACTURER
option as "GOOGLE" for every board, including recent ones which started to
use "Google". I've contacted him about this, and at the end he will change
the string back to "Google".
>> Thanks,
>> Guenter
>>
>> By the way please note that this is the DMI System Vendor and not the DMI
>> > BIOS version string, which indeed starts with "Google_" in the shipping
>> > BIOS
>> > (but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd).
>
> Hmm, I just tried checking out tree from
> https://review.coreboot.org/coreboot.git and do not see this commit:
>
> dtor@dtor-ws:~/coreboot $ git show f56db262e46d3368ee4e5c9e19797853cab382cd
> fatal: bad object f56db262e46d3368ee4e5c9e19797853cab382cd
> dtor@dtor-ws:~/coreboot $ git log --oneline -1 HEAD
> 82d0f91420 (HEAD -> master, origin/master, origin/HEAD) soc/intel/apollolake: enable exception handling in every stage for glk
Sorry, this was a Linux commit hash:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f56db262e46d3368ee4e5c9e19797853cab382cd
> Anyway, if you are overriding the shipping BIOS, then please adjust
> coreboot to use device-tree compatible bindings (via PRP0001 HID and
> _DSD properties - you can check out bindings for PENH device in Caroline
> to see how they can be used). This way we would not need to breed DMI
> quirks.
This should be the correct fix, at least for custom firmware.
As I said, the string in custom firmware will be changed to "Google", so it
won't match the wrong quirk anymore.
Then the ACPI table in custom firmware (and upstream coreboot in the future)
can be fixed too.
But with stock firmware the situation is unchanged: the touchpad would
still not work correctly because it would be recognized as a touchscreen,
since it wouldn't match any quirk and it wouldn't have the correct ACPI
properties.
Because of this, should I still resend a touchpad patch v3 matching "Google"?
Or will maybe Google integrate the ACPI fix into their stock version of
coreboot too?
> Thanks.
Cheers,
Vittorio G
^ permalink raw reply
* Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
From: Tetsuo Handa @ 2018-04-28 2:37 UTC (permalink / raw)
To: syzbot, syzkaller-bugs
Cc: Theodore Y. Ts'o, Dmitry Torokhov,
linux-input@vger.kernel.org, lkml, Henrik Rydberg
In-Reply-To: <20180424125541.GB4189@thunk.org>
OK. Patch was sent to linux.git as 6c1e851c4edc13a4.
#syz fix: random: fix possible sleeping allocation from irq context
^ permalink raw reply
* Re: [PATCH v2] xen/kbdif: Add features to control keyboard and pointer
From: Konrad Rzeszutek Wilk @ 2018-04-27 17:09 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, linux-input, dmitry.torokhov, jandryuk,
Oleksandr_Andrushchenko@epam.com
In-Reply-To: <c079caec-4e8f-de68-00c1-4870854f65e4@gmail.com>
On Fri, Apr 27, 2018 at 06:19:35PM +0300, Oleksandr Andrushchenko wrote:
> On 04/27/2018 06:11 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Apr 27, 2018 at 09:58:11AM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > >
> > > It is now not fully possible to control if and which virtual devices
> > > are created by the frontend, e.g. keyboard and pointer devices
> > > are always created and multi-touch device is created if the
> > s/is/are/
> why? "and multi-touch *device is* created"
>
> > > backend advertises multi-touch support. In some cases this
> > Can you mention under which backend node those devices appear?
> These are created under frontend nodes as these are
> to configure individual frontends
> > > behavior is not desirable and better control over the frontend's
> > > configuration is required.
> > > Add new XenStore feature fields, so it is possible to individually
> > > control set of exposed virtual devices for each guest OS:
> > > - set feature-keyboard to 0 if no keyboard device needs to be created
> > > - set feature-pointer to 0 if no pointer device needs to be created
> > I am thinking that this should be just called 'feature-disable-keyboard'
> > or such. And it being there in the first place would signify '1' by default?
> I just tried to be aligned with multi-touch which is
> "feature-multi-touch". But if you are ok with
> "feature-disable-keyboard/pointer" then I can re-work it
> this way.
I think disable works nicer - that way you know for sure what the purpose
is and there is no confusion about the other features.
And the absence of it by default implies you are OK having it be used.
> > > Keep old behavior by default.
> > >
> > > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > > ---
> > > xen/include/public/io/kbdif.h | 19 ++++++++++++++++++-
> > > 1 file changed, 18 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> > > index 3ce54e9a44c1..ac92e466fd9c 100644
> > > --- a/xen/include/public/io/kbdif.h
> > > +++ b/xen/include/public/io/kbdif.h
> > > @@ -49,7 +49,22 @@
> > > *
> > > * Capable backend advertises supported features by publishing
> > > * corresponding entries in XenStore and puts 1 as the value of the entry.
> > > - * If a feature is not supported then 0 must be set or feature entry omitted.
> > > + * If not otherwise noted if a feature is not supported then 0 must be set
> > > + * or feature entry omitted.
> > Huh? I am not sure what you are saying there.
> > > + *
> > > + * feature-keyboard
> > > + * Values: <uint>
> > > + *
> > > + * If no virtual keyboard device to be exposed by the frontend then
> > > + * this must be set to 0. If feature entry omitted or not set its
> > > + * value defaults to 1.
> > Are you saying:
> > "If there is no need to expose a virtual keyboard device then this must be
> > set to 0. By default it is 1 and it is assumed that any frontend that does
> > not probe this flag will assume the value of 1. "?
> yeap ;)
> > > + *
> > > + * feature-pointer
> > > + * Values: <uint>
> > > + *
> > > + * If no virtual pointer device to be exposed by the frontend then
> > > + * this must be set to 0. If feature entry omitted or not set its
> > > + * value defaults to 1.
> > Ditto?
> > > *
> > > * feature-abs-pointer
> > > * Values: <uint>
> > > @@ -177,6 +192,8 @@
> > > #define XENKBD_DRIVER_NAME "vkbd"
> > > +#define XENKBD_FIELD_FEAT_KEYBOARD "feature-keyboard"
> > > +#define XENKBD_FIELD_FEAT_POINTER "feature-pointer"
> > How about just call it '
> >
> > feature-disable-keyboard
> > feature-disable-keyboard
> See above, I'm fine with that. If we agree on "disable"
> semantics I will re-work the patch.
> > > #define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
> > > #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
> > > #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
> > > --
> > > 2.17.0
> > >
> Thank you,
> Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2] xen/kbdif: Add features to control keyboard and pointer
From: Oleksandr Andrushchenko @ 2018-04-27 15:19 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Oleksandr_Andrushchenko@epam.com
Cc: xen-devel, dmitry.torokhov, jandryuk, linux-input
In-Reply-To: <20180427151128.GC29734@char.us.oracle.com>
On 04/27/2018 06:11 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 27, 2018 at 09:58:11AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> It is now not fully possible to control if and which virtual devices
>> are created by the frontend, e.g. keyboard and pointer devices
>> are always created and multi-touch device is created if the
> s/is/are/
why? "and multi-touch *device is* created"
>> backend advertises multi-touch support. In some cases this
> Can you mention under which backend node those devices appear?
These are created under frontend nodes as these are
to configure individual frontends
>> behavior is not desirable and better control over the frontend's
>> configuration is required.
>> Add new XenStore feature fields, so it is possible to individually
>> control set of exposed virtual devices for each guest OS:
>> - set feature-keyboard to 0 if no keyboard device needs to be created
>> - set feature-pointer to 0 if no pointer device needs to be created
> I am thinking that this should be just called 'feature-disable-keyboard'
> or such. And it being there in the first place would signify '1' by default?
I just tried to be aligned with multi-touch which is
"feature-multi-touch". But if you are ok with
"feature-disable-keyboard/pointer" then I can re-work it
this way.
>> Keep old behavior by default.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> xen/include/public/io/kbdif.h | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>> index 3ce54e9a44c1..ac92e466fd9c 100644
>> --- a/xen/include/public/io/kbdif.h
>> +++ b/xen/include/public/io/kbdif.h
>> @@ -49,7 +49,22 @@
>> *
>> * Capable backend advertises supported features by publishing
>> * corresponding entries in XenStore and puts 1 as the value of the entry.
>> - * If a feature is not supported then 0 must be set or feature entry omitted.
>> + * If not otherwise noted if a feature is not supported then 0 must be set
>> + * or feature entry omitted.
> Huh? I am not sure what you are saying there.
>> + *
>> + * feature-keyboard
>> + * Values: <uint>
>> + *
>> + * If no virtual keyboard device to be exposed by the frontend then
>> + * this must be set to 0. If feature entry omitted or not set its
>> + * value defaults to 1.
> Are you saying:
> "If there is no need to expose a virtual keyboard device then this must be
> set to 0. By default it is 1 and it is assumed that any frontend that does
> not probe this flag will assume the value of 1. "?
yeap ;)
>> + *
>> + * feature-pointer
>> + * Values: <uint>
>> + *
>> + * If no virtual pointer device to be exposed by the frontend then
>> + * this must be set to 0. If feature entry omitted or not set its
>> + * value defaults to 1.
> Ditto?
>> *
>> * feature-abs-pointer
>> * Values: <uint>
>> @@ -177,6 +192,8 @@
>>
>> #define XENKBD_DRIVER_NAME "vkbd"
>>
>> +#define XENKBD_FIELD_FEAT_KEYBOARD "feature-keyboard"
>> +#define XENKBD_FIELD_FEAT_POINTER "feature-pointer"
> How about just call it '
>
> feature-disable-keyboard
> feature-disable-keyboard
See above, I'm fine with that. If we agree on "disable"
semantics I will re-work the patch.
>> #define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
>> #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
>> #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
>> --
>> 2.17.0
>>
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2] xen/kbdif: Add features to control keyboard and pointer
From: Konrad Rzeszutek Wilk @ 2018-04-27 15:11 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, dmitry.torokhov, jandryuk, Oleksandr Andrushchenko,
linux-input
In-Reply-To: <20180427065811.23950-1-andr2000@gmail.com>
On Fri, Apr 27, 2018 at 09:58:11AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> It is now not fully possible to control if and which virtual devices
> are created by the frontend, e.g. keyboard and pointer devices
> are always created and multi-touch device is created if the
s/is/are/
> backend advertises multi-touch support. In some cases this
Can you mention under which backend node those devices appear?
> behavior is not desirable and better control over the frontend's
> configuration is required.
>
> Add new XenStore feature fields, so it is possible to individually
> control set of exposed virtual devices for each guest OS:
> - set feature-keyboard to 0 if no keyboard device needs to be created
> - set feature-pointer to 0 if no pointer device needs to be created
I am thinking that this should be just called 'feature-disable-keyboard'
or such. And it being there in the first place would signify '1' by default?
>
> Keep old behavior by default.
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
> xen/include/public/io/kbdif.h | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 3ce54e9a44c1..ac92e466fd9c 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -49,7 +49,22 @@
> *
> * Capable backend advertises supported features by publishing
> * corresponding entries in XenStore and puts 1 as the value of the entry.
> - * If a feature is not supported then 0 must be set or feature entry omitted.
> + * If not otherwise noted if a feature is not supported then 0 must be set
> + * or feature entry omitted.
Huh? I am not sure what you are saying there.
> + *
> + * feature-keyboard
> + * Values: <uint>
> + *
> + * If no virtual keyboard device to be exposed by the frontend then
> + * this must be set to 0. If feature entry omitted or not set its
> + * value defaults to 1.
Are you saying:
"If there is no need to expose a virtual keyboard device then this must be
set to 0. By default it is 1 and it is assumed that any frontend that does
not probe this flag will assume the value of 1. "?
> + *
> + * feature-pointer
> + * Values: <uint>
> + *
> + * If no virtual pointer device to be exposed by the frontend then
> + * this must be set to 0. If feature entry omitted or not set its
> + * value defaults to 1.
Ditto?
> *
> * feature-abs-pointer
> * Values: <uint>
> @@ -177,6 +192,8 @@
>
> #define XENKBD_DRIVER_NAME "vkbd"
>
> +#define XENKBD_FIELD_FEAT_KEYBOARD "feature-keyboard"
> +#define XENKBD_FIELD_FEAT_POINTER "feature-pointer"
How about just call it '
feature-disable-keyboard
feature-disable-keyboard
> #define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
> #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
> #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
> --
> 2.17.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation
From: Rob Herring @ 2018-04-27 14:51 UTC (permalink / raw)
To: Baolin Wang
Cc: dmitry.torokhov, mark.rutland, orsonzhai, zhang.lyra, linux-input,
devicetree, linux-kernel, xiaotong.lu
In-Reply-To: <e2f85ec0b1fb66baa41dd85bb31e8113e23c704b.1524733425.git.baolin.wang@linaro.org>
On Thu, Apr 26, 2018 at 05:12:33PM +0800, Baolin Wang wrote:
> From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
>
> This patch adds the binding documentation for Spreadtrum SC27xx series
> vibrator device.
>
> Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> Changes since v2:
> - No updates.
>
> Changes since v1:
> - No updates.
> ---
> .../bindings/input/sprd,sc27xx-vibra.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
>
> diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
> new file mode 100644
> index 0000000..92ead29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
> @@ -0,0 +1,12 @@
> +Spreadtrum SC27xx PMIC Vibrator
> +
> +Required properties:
> +- compatible: should be "sprd,sc27xx-vibrator".
> +- reg: address of vibrator control register.
> +
> +Example :
> +
> +vibrator@eb4 {
> + compatible = "sprd,sc27xx-vibrator";
> + reg = <0xeb4>;
What bus is this on? A mmio bus needs a length. Is this part of some
other block?
Rob
^ permalink raw reply
* Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata
From: Wolfram Sang @ 2018-04-27 10:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Wolfram Sang, linux-kernel, linux-renesas-soc, kernel-janitors,
Vladimir Zapolskiy, Sylvain Lemieux, Rakesh Iyer, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, linux-input, linux-arm-kernel,
linux-tegra
In-Reply-To: <20180426212327.GB210716@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
Hi Dmitry,
> > Isn't it actually the other way around? platform_get_drvdata() is a
> > convenience function to access driver_data which is embedded in struct
> > device?
>
> I guess it depends on how you read it. I always considered it separate
> because none (?) of the bus implementation assert this in comments to
> XXX_get_drvdata().
Well, even in the case somebody will implement a custom driver_data for
platform_devices, this person will need to convert all current users to
'dev_get_drvdata(&pdev->dev);' first in order to avoid regressions, I'd
think. This is what my patch does right now (but merely for overhead
reasons). Or?
> > > in the future, so I'd prefer keep using the proper accessors for the
> > > objects we are dealing with.
> >
> > Exactly. I'd just argue, the object we are dealing with, declared in the
> > PM functions, is a struct device.
>
> No, the driver does not create a generic device, it actually creates a
> platform device, or i2c client, or spi, or something else. The fact that
True.
> suspend and resume routines have generic device as their argument has
> more to do with the language limitation rather than reflection of true
> type of the objects we are dealing with.
Ok, can be argued. I'd personally still go for the gain, but I won't
push harder than this mail.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: samsung: Use gpio_is_valid()
From: Sylwester Nawrocki @ 2018-04-27 9:34 UTC (permalink / raw)
To: Arvind Yadav
Cc: alsa-devel, jkosina, jikos, linux-kernel, benjamin.tissoires,
linux-input
In-Reply-To: <f7e9ff7d5d7c559967e9d63f3caff478e05017e8.1524819053.git.arvind.yadav.cs@gmail.com>
Hi Arvind,
On 04/27/2018 10:56 AM, Arvind Yadav wrote:
> Replace the manual validity checks for the GPIO with the
> gpio_is_valid().
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
The patch looks good to me but you need to send it directly
to the ASoC maintainers to have it applied.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid()
From: Peter Ujfalusi @ 2018-04-27 9:33 UTC (permalink / raw)
To: Arvind Yadav, jikos, benjamin.tissoires, jkosina
Cc: alsa-devel, linux-kernel, linux-input
In-Reply-To: <195792a282b569037357ca17e4baad19893f0609.1524819052.git.arvind.yadav.cs@gmail.com>
On 2018-04-27 11:56, Arvind Yadav wrote:
> Replace the manual validity checks for the GPIO with the
> gpio_is_valid().
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> sound/soc/codecs/tpa6130a2.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
> index 616cd4b..18f32b9 100644
> --- a/sound/soc/codecs/tpa6130a2.c
> +++ b/sound/soc/codecs/tpa6130a2.c
> @@ -62,7 +62,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
> return ret;
> }
> /* Power on */
> - if (data->power_gpio >= 0)
> + if (gpio_is_valid(data->power_gpio))
> gpio_set_value(data->power_gpio, 1);
>
> /* Sync registers */
> @@ -72,7 +72,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
> dev_err(data->dev,
> "Failed to sync registers: %d\n", ret);
> regcache_cache_only(data->regmap, true);
> - if (data->power_gpio >= 0)
> + if (gpio_is_valid(data->power_gpio))
> gpio_set_value(data->power_gpio, 0);
> ret2 = regulator_disable(data->supply);
> if (ret2 != 0)
> @@ -89,7 +89,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
> regcache_cache_only(data->regmap, true);
>
> /* Power off */
> - if (data->power_gpio >= 0)
> + if (gpio_is_valid(data->power_gpio))
> gpio_set_value(data->power_gpio, 0);
>
> ret = regulator_disable(data->supply);
> @@ -259,7 +259,7 @@ static int tpa6130a2_probe(struct i2c_client *client,
>
> data->id = id->driver_data;
>
> - if (data->power_gpio >= 0) {
> + if (gpio_is_valid(data->power_gpio)) {
> ret = devm_gpio_request(dev, data->power_gpio,
> "tpa6130a2 enable");
> if (ret < 0) {
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: tlv320dac33: Use gpio_is_valid()
From: Peter Ujfalusi @ 2018-04-27 9:33 UTC (permalink / raw)
To: Arvind Yadav, jikos, benjamin.tissoires, jkosina
Cc: alsa-devel, linux-kernel, linux-input
In-Reply-To: <b61f3ee038bc0f577e60256c71a68bea783d0a13.1524819052.git.arvind.yadav.cs@gmail.com>
On 2018-04-27 11:56, Arvind Yadav wrote:
> Replace the manual validity checks for the GPIO with the
> gpio_is_valid().
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> sound/soc/codecs/tlv320dac33.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
> index a957eae..c23b9db 100644
> --- a/sound/soc/codecs/tlv320dac33.c
> +++ b/sound/soc/codecs/tlv320dac33.c
> @@ -397,13 +397,13 @@ static int dac33_hard_power(struct snd_soc_component *component, int power)
> goto exit;
> }
>
> - if (dac33->power_gpio >= 0)
> + if (gpio_is_valid(dac33->power_gpio))
> gpio_set_value(dac33->power_gpio, 1);
>
> dac33->chip_power = 1;
> } else {
> dac33_soft_power(component, 0);
> - if (dac33->power_gpio >= 0)
> + if (gpio_is_valid(dac33->power_gpio))
> gpio_set_value(dac33->power_gpio, 0);
>
> ret = regulator_bulk_disable(ARRAY_SIZE(dac33->supplies),
> @@ -1519,7 +1519,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
> dac33->fifo_mode = DAC33_FIFO_BYPASS;
>
> /* Check if the reset GPIO number is valid and request it */
> - if (dac33->power_gpio >= 0) {
> + if (gpio_is_valid(dac33->power_gpio)) {
> ret = gpio_request(dac33->power_gpio, "tlv320dac33 reset");
> if (ret < 0) {
> dev_err(&client->dev,
> @@ -1548,7 +1548,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
>
> return ret;
> err_get:
> - if (dac33->power_gpio >= 0)
> + if (gpio_is_valid(dac33->power_gpio))
> gpio_free(dac33->power_gpio);
> err_gpio:
> return ret;
> @@ -1561,7 +1561,7 @@ static int dac33_i2c_remove(struct i2c_client *client)
> if (unlikely(dac33->chip_power))
> dac33_hard_power(dac33->component, 0);
>
> - if (dac33->power_gpio >= 0)
> + if (gpio_is_valid(dac33->power_gpio))
> gpio_free(dac33->power_gpio);
>
> return 0;
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [PATCH 3/3] ASoC: samsung: Use gpio_is_valid()
From: Arvind Yadav @ 2018-04-27 8:56 UTC (permalink / raw)
To: jikos, benjamin.tissoires, jkosina; +Cc: linux-kernel, linux-input, alsa-devel
In-Reply-To: <cover.1524819051.git.arvind.yadav.cs@gmail.com>
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
sound/soc/samsung/s3c24xx_simtec.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/samsung/s3c24xx_simtec.c b/sound/soc/samsung/s3c24xx_simtec.c
index 6de63f3..23e8ef9d 100644
--- a/sound/soc/samsung/s3c24xx_simtec.c
+++ b/sound/soc/samsung/s3c24xx_simtec.c
@@ -229,7 +229,7 @@ static int attach_gpio_amp(struct device *dev,
int ret;
/* attach gpio amp gain (if any) */
- if (pdata->amp_gain[0] > 0) {
+ if (gpio_is_valid(pdata->amp_gain[0])) {
ret = gpio_request(pd->amp_gain[0], "gpio-amp-gain0");
if (ret) {
dev_err(dev, "cannot get amp gpio gain0\n");
@@ -248,7 +248,7 @@ static int attach_gpio_amp(struct device *dev,
}
/* note, currently we assume GPA0 isn't valid amp */
- if (pdata->amp_gpio > 0) {
+ if (gpio_is_valid(pdata->amp_gpio)) {
ret = gpio_request(pd->amp_gpio, "gpio-amp");
if (ret) {
dev_err(dev, "cannot get amp gpio %d (%d)\n",
@@ -263,7 +263,7 @@ static int attach_gpio_amp(struct device *dev,
return 0;
err_amp:
- if (pd->amp_gain[0] > 0) {
+ if (gpio_is_valid(pd->amp_gain[0])) {
gpio_free(pd->amp_gain[0]);
gpio_free(pd->amp_gain[1]);
}
@@ -273,12 +273,12 @@ static int attach_gpio_amp(struct device *dev,
static void detach_gpio_amp(struct s3c24xx_audio_simtec_pdata *pd)
{
- if (pd->amp_gain[0] > 0) {
+ if (gpio_is_valid(pd->amp_gain[0])) {
gpio_free(pd->amp_gain[0]);
gpio_free(pd->amp_gain[1]);
}
- if (pd->amp_gpio > 0)
+ if (gpio_is_valid(pd->amp_gpio))
gpio_free(pd->amp_gpio);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid()
From: Arvind Yadav @ 2018-04-27 8:56 UTC (permalink / raw)
To: jikos, benjamin.tissoires, jkosina; +Cc: alsa-devel, linux-kernel, linux-input
In-Reply-To: <cover.1524819051.git.arvind.yadav.cs@gmail.com>
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
sound/soc/codecs/tpa6130a2.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 616cd4b..18f32b9 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -62,7 +62,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
return ret;
}
/* Power on */
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 1);
/* Sync registers */
@@ -72,7 +72,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
dev_err(data->dev,
"Failed to sync registers: %d\n", ret);
regcache_cache_only(data->regmap, true);
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
ret2 = regulator_disable(data->supply);
if (ret2 != 0)
@@ -89,7 +89,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
regcache_cache_only(data->regmap, true);
/* Power off */
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
ret = regulator_disable(data->supply);
@@ -259,7 +259,7 @@ static int tpa6130a2_probe(struct i2c_client *client,
data->id = id->driver_data;
- if (data->power_gpio >= 0) {
+ if (gpio_is_valid(data->power_gpio)) {
ret = devm_gpio_request(dev, data->power_gpio,
"tpa6130a2 enable");
if (ret < 0) {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ASoC: tlv320dac33: Use gpio_is_valid()
From: Arvind Yadav @ 2018-04-27 8:56 UTC (permalink / raw)
To: jikos, benjamin.tissoires, jkosina; +Cc: linux-kernel, linux-input, alsa-devel
In-Reply-To: <cover.1524819051.git.arvind.yadav.cs@gmail.com>
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
sound/soc/codecs/tlv320dac33.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index a957eae..c23b9db 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -397,13 +397,13 @@ static int dac33_hard_power(struct snd_soc_component *component, int power)
goto exit;
}
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_set_value(dac33->power_gpio, 1);
dac33->chip_power = 1;
} else {
dac33_soft_power(component, 0);
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_set_value(dac33->power_gpio, 0);
ret = regulator_bulk_disable(ARRAY_SIZE(dac33->supplies),
@@ -1519,7 +1519,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
dac33->fifo_mode = DAC33_FIFO_BYPASS;
/* Check if the reset GPIO number is valid and request it */
- if (dac33->power_gpio >= 0) {
+ if (gpio_is_valid(dac33->power_gpio)) {
ret = gpio_request(dac33->power_gpio, "tlv320dac33 reset");
if (ret < 0) {
dev_err(&client->dev,
@@ -1548,7 +1548,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
return ret;
err_get:
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_free(dac33->power_gpio);
err_gpio:
return ret;
@@ -1561,7 +1561,7 @@ static int dac33_i2c_remove(struct i2c_client *client)
if (unlikely(dac33->chip_power))
dac33_hard_power(dac33->component, 0);
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_free(dac33->power_gpio);
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] ASoC: Use gpio_is_valid()
From: Arvind Yadav @ 2018-04-27 8:56 UTC (permalink / raw)
To: jikos, benjamin.tissoires, jkosina; +Cc: linux-kernel, linux-input, alsa-devel
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Arvind Yadav (3):
[PATCH 1/3] ASoC: tlv320dac33: Use gpio_is_valid()
[PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid()
[PATCH 3/3] ASoC: samsung: Use gpio_is_valid()
sound/soc/codecs/tlv320dac33.c | 10 +++++-----
sound/soc/codecs/tpa6130a2.c | 8 ++++----
sound/soc/samsung/s3c24xx_simtec.c | 10 +++++-----
3 files changed, 14 insertions(+), 14 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2] xen/kbdif: Add features to control keyboard and pointer
From: Oleksandr Andrushchenko @ 2018-04-27 6:58 UTC (permalink / raw)
To: linux-input, xen-devel, konrad.wilk, dmitry.torokhov
Cc: andr2000, Oleksandr Andrushchenko, jandryuk
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
It is now not fully possible to control if and which virtual devices
are created by the frontend, e.g. keyboard and pointer devices
are always created and multi-touch device is created if the
backend advertises multi-touch support. In some cases this
behavior is not desirable and better control over the frontend's
configuration is required.
Add new XenStore feature fields, so it is possible to individually
control set of exposed virtual devices for each guest OS:
- set feature-keyboard to 0 if no keyboard device needs to be created
- set feature-pointer to 0 if no pointer device needs to be created
Keep old behavior by default.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
xen/include/public/io/kbdif.h | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 3ce54e9a44c1..ac92e466fd9c 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -49,7 +49,22 @@
*
* Capable backend advertises supported features by publishing
* corresponding entries in XenStore and puts 1 as the value of the entry.
- * If a feature is not supported then 0 must be set or feature entry omitted.
+ * If not otherwise noted if a feature is not supported then 0 must be set
+ * or feature entry omitted.
+ *
+ * feature-keyboard
+ * Values: <uint>
+ *
+ * If no virtual keyboard device to be exposed by the frontend then
+ * this must be set to 0. If feature entry omitted or not set its
+ * value defaults to 1.
+ *
+ * feature-pointer
+ * Values: <uint>
+ *
+ * If no virtual pointer device to be exposed by the frontend then
+ * this must be set to 0. If feature entry omitted or not set its
+ * value defaults to 1.
*
* feature-abs-pointer
* Values: <uint>
@@ -177,6 +192,8 @@
#define XENKBD_DRIVER_NAME "vkbd"
+#define XENKBD_FIELD_FEAT_KEYBOARD "feature-keyboard"
+#define XENKBD_FIELD_FEAT_POINTER "feature-pointer"
#define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
#define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
--
2.17.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH] xen/kbdif: Add frontend's virtual device options
From: Oleksandr Andrushchenko @ 2018-04-27 6:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: xen-devel, jandryuk, Oleksandr Andrushchenko, linux-input
In-Reply-To: <20180426211439.GA210716@dtor-ws>
On 04/27/2018 12:14 AM, Dmitry Torokhov wrote:
> Hi Oleksandr,
>
> On Tue, Apr 24, 2018 at 10:31:38AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> It is now not possible to control if and which virtual devices
>> are created by the frontend, e.g. keyboard and pointer devices
>> are always created and multi-touch device is created if the
>> backend advertises multi-touch support. In some cases this
>> behavior is not desirable and better control over the frontend's
>> configuration is required.
>>
>> Add new frontend options, so it is possible to individually
>> control set of exposed virtual devices for each guest OS:
>> - set opt-no-pointer if no pointer device needs to be created
>> - set opt-no-keyboard if no keyboard device needs to be created
>> - set opt-no-multi-touch if no multi-touch device needs to be created
>>
>> Keep old behavior by default.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> xen/include/public/io/kbdif.h | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>> index 3ce54e9a44c1..703433156c1f 100644
>> --- a/xen/include/public/io/kbdif.h
>> +++ b/xen/include/public/io/kbdif.h
>> @@ -132,6 +132,29 @@
>> * OBSOLETE, not recommended for use.
>> * PFN of the shared page.
>> *
>> + *--------------------------- Frontend Options -------------------------------
>> + *
>> + * For the below options if corresponding XenStore entry omitted,
>> + * then the value must be treated as set to 0.
>> + *
>> + * opt-no-pointer
>> + * Values: <uint>
>> + *
>> + * If no virtual pointer device to be exposed by the frontend then
>> + * this must be set to 1.
>> + *
>> + * opt-no-keyboard
>> + * Values: <uint>
>> + *
>> + * If no virtual keyboard device to be exposed by the frontend then
>> + * this must be set to 1.
>> + *
>> + * opt-no-multi-touch
>> + * Values: <uint>
>> + *
>> + * If no virtual multi-touch device to be exposed by the frontend then
>> + * this must be set to 1.
>> + *
>> *----------------------- Multi-touch Device Parameters -----------------------
>> *
>> * multi-touch-num-contacts
>> @@ -181,6 +204,9 @@
>> #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
>> #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
>> #define XENKBD_FIELD_REQ_MTOUCH "request-multi-touch"
>> +#define XENKBD_FIELD_OPT_NO_PTR "opt-no-pointer"
>> +#define XENKBD_FIELD_OPT_NO_KBD "opt-no-keyboard"
>> +#define XENKBD_FIELD_OPT_NO_MTOUCH "opt-no-multi-touch"
> So we have "feature-multi-touch" and "opt-no-multi-touch". What is the
> difference between feature and option?
Indeed, it can be made simpler.
This is how it looks in XenStore for a given frontend:
/local/domain/2/device/vkbd/0/feature-multi-touch = "1"
/local/domain/2/device/vkbd/0/request-multi-touch = "1"
Thus, feature-multi-touch field already controls if multi-touch
device is created *per frontend*, so the multi-touch control
is already there. (request-multi-touch field is set by the
frontend to request multi-touch events to be sent by the backend,
e.g. this is sort of negotiation that backend offers multi-touch
to frontend and if frontend is capable and willing to support that
it then replies by setting this field).
So, "opt-no-multi-touch" will be removed from the protocol.
>
> Also, for the pointer and keyboard, if we decide that features and
> options can be merged, can we keep them positive (i.e.
> "feature-keyboard" or "feature-rel-pointer") and mention in the protocol
> spec that they are assumed to be present by default?
As Dmitry suggested at [1]:
"I think you can have them as "feature-pointer" and "feature-keyboard"
(no negation), but assume not present considered enabled. I.e.
kbd = xenbus_read_unsigned(..., XENKBD_FIELD_FEAT_KEYBOARD, 1);
if (kbd) {
...
}
"
So, I'll add *per frontend* features:
- feature-keyboard
- feature-pointer (without "rel", we just need to enable the pointer
device which is by default "rel": there is a dedicated feature for
"abs" - feature-abs-pointer).
/local/domain/2/device/vkbd/0/feature-keyboard = "1"
/local/domain/2/device/vkbd/0/feature-pointer = "1"
For backward compatibility the default will be "1" if the field is
not present. opt-no-keyboard and opt-no-pointer will be removed.
I will send v1 with the changes above.
>
>> #define XENKBD_FIELD_RING_GREF "page-gref"
>> #define XENKBD_FIELD_EVT_CHANNEL "event-channel"
>> #define XENKBD_FIELD_WIDTH "width"
>> --
>> 2.17.0
>>
> Thanks.
>
Thank you,
Oleksandr
[1] https://lkml.org/lkml/2018/4/26/865
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata
From: Dmitry Torokhov @ 2018-04-26 21:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Wolfram Sang, linux-kernel, linux-renesas-soc, kernel-janitors,
Vladimir Zapolskiy, Sylvain Lemieux, Rakesh Iyer, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, linux-input, linux-arm-kernel,
linux-tegra
In-Reply-To: <20180426200401.lvqiy4gnchkwr4qw@ninjato>
On Thu, Apr 26, 2018 at 10:04:01PM +0200, Wolfram Sang wrote:
> Hi Dmitry,
>
> > > We should get drvdata from struct device directly. Going via
> > > platform_device is an unneeded step back and forth.
> >
> > I consider the fact that platform device's driver data is accessible via
> > device driver data being implementation detail that may or may not change
>
> Isn't it actually the other way around? platform_get_drvdata() is a
> convenience function to access driver_data which is embedded in struct
> device?
I guess it depends on how you read it. I always considered it separate
because none (?) of the bus implementation assert this in comments to
XXX_get_drvdata().
>
> > in the future, so I'd prefer keep using the proper accessors for the
> > objects we are dealing with.
>
> Exactly. I'd just argue, the object we are dealing with, declared in the
> PM functions, is a struct device.
No, the driver does not create a generic device, it actually creates a
platform device, or i2c client, or spi, or something else. The fact that
suspend and resume routines have generic device as their argument has
more to do with the language limitation rather than reflection of true
type of the objects we are dealing with.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] xen/kbdif: Add frontend's virtual device options
From: Dmitry Torokhov @ 2018-04-26 21:14 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, jandryuk, Oleksandr Andrushchenko, linux-input
In-Reply-To: <20180424073138.19866-1-andr2000@gmail.com>
Hi Oleksandr,
On Tue, Apr 24, 2018 at 10:31:38AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> It is now not possible to control if and which virtual devices
> are created by the frontend, e.g. keyboard and pointer devices
> are always created and multi-touch device is created if the
> backend advertises multi-touch support. In some cases this
> behavior is not desirable and better control over the frontend's
> configuration is required.
>
> Add new frontend options, so it is possible to individually
> control set of exposed virtual devices for each guest OS:
> - set opt-no-pointer if no pointer device needs to be created
> - set opt-no-keyboard if no keyboard device needs to be created
> - set opt-no-multi-touch if no multi-touch device needs to be created
>
> Keep old behavior by default.
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
> xen/include/public/io/kbdif.h | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 3ce54e9a44c1..703433156c1f 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -132,6 +132,29 @@
> * OBSOLETE, not recommended for use.
> * PFN of the shared page.
> *
> + *--------------------------- Frontend Options -------------------------------
> + *
> + * For the below options if corresponding XenStore entry omitted,
> + * then the value must be treated as set to 0.
> + *
> + * opt-no-pointer
> + * Values: <uint>
> + *
> + * If no virtual pointer device to be exposed by the frontend then
> + * this must be set to 1.
> + *
> + * opt-no-keyboard
> + * Values: <uint>
> + *
> + * If no virtual keyboard device to be exposed by the frontend then
> + * this must be set to 1.
> + *
> + * opt-no-multi-touch
> + * Values: <uint>
> + *
> + * If no virtual multi-touch device to be exposed by the frontend then
> + * this must be set to 1.
> + *
> *----------------------- Multi-touch Device Parameters -----------------------
> *
> * multi-touch-num-contacts
> @@ -181,6 +204,9 @@
> #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
> #define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
> #define XENKBD_FIELD_REQ_MTOUCH "request-multi-touch"
> +#define XENKBD_FIELD_OPT_NO_PTR "opt-no-pointer"
> +#define XENKBD_FIELD_OPT_NO_KBD "opt-no-keyboard"
> +#define XENKBD_FIELD_OPT_NO_MTOUCH "opt-no-multi-touch"
So we have "feature-multi-touch" and "opt-no-multi-touch". What is the
difference between feature and option?
Also, for the pointer and keyboard, if we decide that features and
options can be merged, can we keep them positive (i.e.
"feature-keyboard" or "feature-rel-pointer") and mention in the protocol
spec that they are assumed to be present by default?
> #define XENKBD_FIELD_RING_GREF "page-gref"
> #define XENKBD_FIELD_EVT_CHANNEL "event-channel"
> #define XENKBD_FIELD_WIDTH "width"
> --
> 2.17.0
>
Thanks.
--
Dmitry
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata
From: Wolfram Sang @ 2018-04-26 20:04 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Wolfram Sang, linux-kernel, linux-renesas-soc, kernel-janitors,
Vladimir Zapolskiy, Sylvain Lemieux, Rakesh Iyer, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, linux-input, linux-arm-kernel,
linux-tegra
In-Reply-To: <20180426191947.GC162443@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
Hi Dmitry,
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
>
> I consider the fact that platform device's driver data is accessible via
> device driver data being implementation detail that may or may not change
Isn't it actually the other way around? platform_get_drvdata() is a
convenience function to access driver_data which is embedded in struct
device?
> in the future, so I'd prefer keep using the proper accessors for the
> objects we are dealing with.
Exactly. I'd just argue, the object we are dealing with, declared in the
PM functions, is a struct device.
Thanks for the comment,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-04-26 19:27 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Juergen Gross, xen-devel, linux-input, linux-kernel, lyan,
boris.ostrovsky, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <20180426191624.GB162443@dtor-ws>
On 04/26/2018 10:16 PM, Dmitry Torokhov wrote:
> On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote:
>> On 04/23/2018 09:53 PM, Dmitry Torokhov wrote:
>>> On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote:
>>>> On 04/19/2018 02:25 PM, Juergen Gross wrote:
>>>>> On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>
>>>>>> It is now only possible to control if multi-touch virtual device
>>>>>> is created or not (via the corresponding XenStore entries),
>>>>>> but keyboard and pointer devices are always created.
>>>>> Why don't you want to go that route for keyboard and mouse, too?
>>>>> Or does this really make no sense?
>>>> Well, I would prefer not to touch anything outside Linux and
>>>> this driver. And these settings seem to be implementation specific.
>>>> So, this is why introduce Linux module parameters and don't extend
>>>> the kbdif protocol.
>>> Why do you consider this implementation specific? How other guests
>>> decide to forego creation of relative pointer device or keyboard-like
>>> device?
>>>
>>> You already have "features" for absolute pointing device and multitouch,
>>> so please extend the protocol properly so you indeed do not code
>>> something implementation-specific (i.e. module parameters).
>> Ok, but in order to preserve the default behavior, e.g.
>> pointer and keyboard devices are always created now, I'll have
>> to have reverse features in the protocol:
>> - feature-no-pointer
>> - feature-no-keyboard
>> The above may be set as a part of frontend's configuration and
>> if missed are considered to be set to false.
> I think you can have them as "feature-pointer" and "feature-keyboard"
> (no negation), but assume not present considered enabled. I.e.
>
> kbd = xenbus_read_unsigned(..., XENKBD_FIELD_FEAT_KEYBOARD, 1);
> if (kbd) {
> ...
Thank you for your comments,
could you please take a look at the patch [1] where I am trying
to change the corresponding Xen protocol to fit the requirements?
As we agreed I have to change the protocol first, so this patch is no
longer valid
> }
>
> Thanks.
Thank you,
Oleksandr
[1] https://www.spinics.net/lists/linux-input/msg56094.html
^ permalink raw reply
* Re: [PATCH 20/61] input: keyboard: simplify getting .drvdata
From: Dmitry Torokhov @ 2018-04-26 19:19 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-kernel, linux-renesas-soc, kernel-janitors,
Vladimir Zapolskiy, Sylvain Lemieux, Rakesh Iyer, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, linux-input, linux-arm-kernel,
linux-tegra
In-Reply-To: <20180419140641.27926-21-wsa+renesas@sang-engineering.com>
Hi Wolfram,
On Thu, Apr 19, 2018 at 04:05:50PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
I consider the fact that platform device's driver data is accessible via
device driver data being implementation detail that may or may not change
in the future, so I'd prefer keep using the proper accessors for the
objects we are dealing with.
Thanks.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/input/keyboard/ep93xx_keypad.c | 10 ++++------
> drivers/input/keyboard/imx_keypad.c | 10 ++++------
> drivers/input/keyboard/lpc32xx-keys.c | 6 ++----
> drivers/input/keyboard/matrix_keypad.c | 10 ++++------
> drivers/input/keyboard/omap4-keypad.c | 10 ++++------
> drivers/input/keyboard/pmic8xxx-keypad.c | 6 ++----
> drivers/input/keyboard/pxa27x_keypad.c | 10 ++++------
> drivers/input/keyboard/samsung-keypad.c | 12 ++++--------
> drivers/input/keyboard/snvs_pwrkey.c | 10 ++++------
> drivers/input/keyboard/spear-keyboard.c | 10 ++++------
> drivers/input/keyboard/st-keyscan.c | 6 ++----
> drivers/input/keyboard/tegra-kbc.c | 10 ++++------
> 12 files changed, 42 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/input/keyboard/ep93xx_keypad.c b/drivers/input/keyboard/ep93xx_keypad.c
> index f77b295e0123..7584a03db4b3 100644
> --- a/drivers/input/keyboard/ep93xx_keypad.c
> +++ b/drivers/input/keyboard/ep93xx_keypad.c
> @@ -185,8 +185,7 @@ static void ep93xx_keypad_close(struct input_dev *pdev)
> #ifdef CONFIG_PM_SLEEP
> static int ep93xx_keypad_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
> + struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
> struct input_dev *input_dev = keypad->input_dev;
>
> mutex_lock(&input_dev->mutex);
> @@ -198,7 +197,7 @@ static int ep93xx_keypad_suspend(struct device *dev)
>
> mutex_unlock(&input_dev->mutex);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> enable_irq_wake(keypad->irq);
>
> return 0;
> @@ -206,11 +205,10 @@ static int ep93xx_keypad_suspend(struct device *dev)
>
> static int ep93xx_keypad_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
> + struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
> struct input_dev *input_dev = keypad->input_dev;
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> disable_irq_wake(keypad->irq);
>
> mutex_lock(&input_dev->mutex);
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index 25d61d8d4fc4..56328ced81e2 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -532,8 +532,7 @@ static int imx_keypad_probe(struct platform_device *pdev)
>
> static int __maybe_unused imx_kbd_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct imx_keypad *kbd = platform_get_drvdata(pdev);
> + struct imx_keypad *kbd = dev_get_drvdata(dev);
> struct input_dev *input_dev = kbd->input_dev;
>
> /* imx kbd can wake up system even clock is disabled */
> @@ -544,7 +543,7 @@ static int __maybe_unused imx_kbd_suspend(struct device *dev)
>
> mutex_unlock(&input_dev->mutex);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> enable_irq_wake(kbd->irq);
>
> return 0;
> @@ -552,12 +551,11 @@ static int __maybe_unused imx_kbd_suspend(struct device *dev)
>
> static int __maybe_unused imx_kbd_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct imx_keypad *kbd = platform_get_drvdata(pdev);
> + struct imx_keypad *kbd = dev_get_drvdata(dev);
> struct input_dev *input_dev = kbd->input_dev;
> int ret = 0;
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> disable_irq_wake(kbd->irq);
>
> mutex_lock(&input_dev->mutex);
> diff --git a/drivers/input/keyboard/lpc32xx-keys.c b/drivers/input/keyboard/lpc32xx-keys.c
> index 1dd57ac0e7a2..0831a6f2a9d4 100644
> --- a/drivers/input/keyboard/lpc32xx-keys.c
> +++ b/drivers/input/keyboard/lpc32xx-keys.c
> @@ -279,8 +279,7 @@ static int lpc32xx_kscan_probe(struct platform_device *pdev)
> #ifdef CONFIG_PM_SLEEP
> static int lpc32xx_kscan_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct lpc32xx_kscan_drv *kscandat = platform_get_drvdata(pdev);
> + struct lpc32xx_kscan_drv *kscandat = dev_get_drvdata(dev);
> struct input_dev *input = kscandat->input;
>
> mutex_lock(&input->mutex);
> @@ -297,8 +296,7 @@ static int lpc32xx_kscan_suspend(struct device *dev)
>
> static int lpc32xx_kscan_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct lpc32xx_kscan_drv *kscandat = platform_get_drvdata(pdev);
> + struct lpc32xx_kscan_drv *kscandat = dev_get_drvdata(dev);
> struct input_dev *input = kscandat->input;
> int retval = 0;
>
> diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
> index 41614c185918..73ca55e4babe 100644
> --- a/drivers/input/keyboard/matrix_keypad.c
> +++ b/drivers/input/keyboard/matrix_keypad.c
> @@ -276,12 +276,11 @@ static void matrix_keypad_disable_wakeup(struct matrix_keypad *keypad)
>
> static int matrix_keypad_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct matrix_keypad *keypad = platform_get_drvdata(pdev);
> + struct matrix_keypad *keypad = dev_get_drvdata(dev);
>
> matrix_keypad_stop(keypad->input_dev);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> matrix_keypad_enable_wakeup(keypad);
>
> return 0;
> @@ -289,10 +288,9 @@ static int matrix_keypad_suspend(struct device *dev)
>
> static int matrix_keypad_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct matrix_keypad *keypad = platform_get_drvdata(pdev);
> + struct matrix_keypad *keypad = dev_get_drvdata(dev);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> matrix_keypad_disable_wakeup(keypad);
>
> matrix_keypad_start(keypad->input_dev);
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> index 940d38b08e6b..13578b884ace 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -422,11 +422,10 @@ MODULE_DEVICE_TABLE(of, omap_keypad_dt_match);
> #ifdef CONFIG_PM_SLEEP
> static int omap4_keypad_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
> + struct omap4_keypad *keypad_data = dev_get_drvdata(dev);
> int error;
>
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> error = enable_irq_wake(keypad_data->irq);
> if (!error)
> keypad_data->irq_wake_enabled = true;
> @@ -437,10 +436,9 @@ static int omap4_keypad_suspend(struct device *dev)
>
> static int omap4_keypad_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
> + struct omap4_keypad *keypad_data = dev_get_drvdata(dev);
>
> - if (device_may_wakeup(&pdev->dev) && keypad_data->irq_wake_enabled) {
> + if (device_may_wakeup(dev) && keypad_data->irq_wake_enabled) {
> disable_irq_wake(keypad_data->irq);
> keypad_data->irq_wake_enabled = false;
> }
> diff --git a/drivers/input/keyboard/pmic8xxx-keypad.c b/drivers/input/keyboard/pmic8xxx-keypad.c
> index 98b24ed18752..048a39321298 100644
> --- a/drivers/input/keyboard/pmic8xxx-keypad.c
> +++ b/drivers/input/keyboard/pmic8xxx-keypad.c
> @@ -636,8 +636,7 @@ static int pmic8xxx_kp_probe(struct platform_device *pdev)
> #ifdef CONFIG_PM_SLEEP
> static int pmic8xxx_kp_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pmic8xxx_kp *kp = platform_get_drvdata(pdev);
> + struct pmic8xxx_kp *kp = dev_get_drvdata(dev);
> struct input_dev *input_dev = kp->input;
>
> if (device_may_wakeup(dev)) {
> @@ -656,8 +655,7 @@ static int pmic8xxx_kp_suspend(struct device *dev)
>
> static int pmic8xxx_kp_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pmic8xxx_kp *kp = platform_get_drvdata(pdev);
> + struct pmic8xxx_kp *kp = dev_get_drvdata(dev);
> struct input_dev *input_dev = kp->input;
>
> if (device_may_wakeup(dev)) {
> diff --git a/drivers/input/keyboard/pxa27x_keypad.c b/drivers/input/keyboard/pxa27x_keypad.c
> index d0bdaeadf86d..1f54a3162124 100644
> --- a/drivers/input/keyboard/pxa27x_keypad.c
> +++ b/drivers/input/keyboard/pxa27x_keypad.c
> @@ -666,14 +666,13 @@ static void pxa27x_keypad_close(struct input_dev *dev)
> #ifdef CONFIG_PM_SLEEP
> static int pxa27x_keypad_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pxa27x_keypad *keypad = platform_get_drvdata(pdev);
> + struct pxa27x_keypad *keypad = dev_get_drvdata(dev);
>
> /*
> * If the keypad is used a wake up source, clock can not be disabled.
> * Or it can not detect the key pressing.
> */
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> enable_irq_wake(keypad->irq);
> else
> clk_disable_unprepare(keypad->clk);
> @@ -683,8 +682,7 @@ static int pxa27x_keypad_suspend(struct device *dev)
>
> static int pxa27x_keypad_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pxa27x_keypad *keypad = platform_get_drvdata(pdev);
> + struct pxa27x_keypad *keypad = dev_get_drvdata(dev);
> struct input_dev *input_dev = keypad->input_dev;
> int ret = 0;
>
> @@ -692,7 +690,7 @@ static int pxa27x_keypad_resume(struct device *dev)
> * If the keypad is used as wake up source, the clock is not turned
> * off. So do not need configure it again.
> */
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> disable_irq_wake(keypad->irq);
> } else {
> mutex_lock(&input_dev->mutex);
> diff --git a/drivers/input/keyboard/samsung-keypad.c b/drivers/input/keyboard/samsung-keypad.c
> index 316414465c77..27790a8a44f5 100644
> --- a/drivers/input/keyboard/samsung-keypad.c
> +++ b/drivers/input/keyboard/samsung-keypad.c
> @@ -466,8 +466,7 @@ static int samsung_keypad_remove(struct platform_device *pdev)
> #ifdef CONFIG_PM
> static int samsung_keypad_runtime_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct samsung_keypad *keypad = platform_get_drvdata(pdev);
> + struct samsung_keypad *keypad = dev_get_drvdata(dev);
> unsigned int val;
> int error;
>
> @@ -490,8 +489,7 @@ static int samsung_keypad_runtime_suspend(struct device *dev)
>
> static int samsung_keypad_runtime_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct samsung_keypad *keypad = platform_get_drvdata(pdev);
> + struct samsung_keypad *keypad = dev_get_drvdata(dev);
> unsigned int val;
>
> if (keypad->stopped)
> @@ -535,8 +533,7 @@ static void samsung_keypad_toggle_wakeup(struct samsung_keypad *keypad,
>
> static int samsung_keypad_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct samsung_keypad *keypad = platform_get_drvdata(pdev);
> + struct samsung_keypad *keypad = dev_get_drvdata(dev);
> struct input_dev *input_dev = keypad->input_dev;
>
> mutex_lock(&input_dev->mutex);
> @@ -553,8 +550,7 @@ static int samsung_keypad_suspend(struct device *dev)
>
> static int samsung_keypad_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct samsung_keypad *keypad = platform_get_drvdata(pdev);
> + struct samsung_keypad *keypad = dev_get_drvdata(dev);
> struct input_dev *input_dev = keypad->input_dev;
>
> mutex_lock(&input_dev->mutex);
> diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> index 53c768b95939..f439f7bd2f5f 100644
> --- a/drivers/input/keyboard/snvs_pwrkey.c
> +++ b/drivers/input/keyboard/snvs_pwrkey.c
> @@ -180,10 +180,9 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
>
> static int __maybe_unused imx_snvs_pwrkey_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> + struct pwrkey_drv_data *pdata = dev_get_drvdata(dev);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> enable_irq_wake(pdata->irq);
>
> return 0;
> @@ -191,10 +190,9 @@ static int __maybe_unused imx_snvs_pwrkey_suspend(struct device *dev)
>
> static int __maybe_unused imx_snvs_pwrkey_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> + struct pwrkey_drv_data *pdata = dev_get_drvdata(dev);
>
> - if (device_may_wakeup(&pdev->dev))
> + if (device_may_wakeup(dev))
> disable_irq_wake(pdata->irq);
>
> return 0;
> diff --git a/drivers/input/keyboard/spear-keyboard.c b/drivers/input/keyboard/spear-keyboard.c
> index 7d25fa338ab4..a0276a3376d2 100644
> --- a/drivers/input/keyboard/spear-keyboard.c
> +++ b/drivers/input/keyboard/spear-keyboard.c
> @@ -288,8 +288,7 @@ static int spear_kbd_remove(struct platform_device *pdev)
>
> static int __maybe_unused spear_kbd_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct spear_kbd *kbd = platform_get_drvdata(pdev);
> + struct spear_kbd *kbd = dev_get_drvdata(dev);
> struct input_dev *input_dev = kbd->input;
> unsigned int rate = 0, mode_ctl_reg, val;
>
> @@ -300,7 +299,7 @@ static int __maybe_unused spear_kbd_suspend(struct device *dev)
>
> mode_ctl_reg = readl_relaxed(kbd->io_base + MODE_CTL_REG);
>
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> if (!enable_irq_wake(kbd->irq))
> kbd->irq_wake_enabled = true;
>
> @@ -341,13 +340,12 @@ static int __maybe_unused spear_kbd_suspend(struct device *dev)
>
> static int __maybe_unused spear_kbd_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct spear_kbd *kbd = platform_get_drvdata(pdev);
> + struct spear_kbd *kbd = dev_get_drvdata(dev);
> struct input_dev *input_dev = kbd->input;
>
> mutex_lock(&input_dev->mutex);
>
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> if (kbd->irq_wake_enabled) {
> kbd->irq_wake_enabled = false;
> disable_irq_wake(kbd->irq);
> diff --git a/drivers/input/keyboard/st-keyscan.c b/drivers/input/keyboard/st-keyscan.c
> index babcfb165e4f..3b4727e4b411 100644
> --- a/drivers/input/keyboard/st-keyscan.c
> +++ b/drivers/input/keyboard/st-keyscan.c
> @@ -218,8 +218,7 @@ static int keyscan_probe(struct platform_device *pdev)
> #ifdef CONFIG_PM_SLEEP
> static int keyscan_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct st_keyscan *keypad = platform_get_drvdata(pdev);
> + struct st_keyscan *keypad = dev_get_drvdata(dev);
> struct input_dev *input = keypad->input_dev;
>
> mutex_lock(&input->mutex);
> @@ -235,8 +234,7 @@ static int keyscan_suspend(struct device *dev)
>
> static int keyscan_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct st_keyscan *keypad = platform_get_drvdata(pdev);
> + struct st_keyscan *keypad = dev_get_drvdata(dev);
> struct input_dev *input = keypad->input_dev;
> int retval = 0;
>
> diff --git a/drivers/input/keyboard/tegra-kbc.c b/drivers/input/keyboard/tegra-kbc.c
> index 875205f445b5..861bfcbd817d 100644
> --- a/drivers/input/keyboard/tegra-kbc.c
> +++ b/drivers/input/keyboard/tegra-kbc.c
> @@ -744,11 +744,10 @@ static void tegra_kbc_set_keypress_interrupt(struct tegra_kbc *kbc, bool enable)
>
> static int tegra_kbc_suspend(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct tegra_kbc *kbc = platform_get_drvdata(pdev);
> + struct tegra_kbc *kbc = dev_get_drvdata(dev);
>
> mutex_lock(&kbc->idev->mutex);
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> disable_irq(kbc->irq);
> del_timer_sync(&kbc->timer);
> tegra_kbc_set_fifo_interrupt(kbc, false);
> @@ -781,12 +780,11 @@ static int tegra_kbc_suspend(struct device *dev)
>
> static int tegra_kbc_resume(struct device *dev)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct tegra_kbc *kbc = platform_get_drvdata(pdev);
> + struct tegra_kbc *kbc = dev_get_drvdata(dev);
> int err = 0;
>
> mutex_lock(&kbc->idev->mutex);
> - if (device_may_wakeup(&pdev->dev)) {
> + if (device_may_wakeup(dev)) {
> disable_irq_wake(kbc->irq);
> tegra_kbc_setup_wakekeys(kbc, false);
> /* We will use fifo interrupts for key detection. */
> --
> 2.11.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration
From: Dmitry Torokhov @ 2018-04-26 19:16 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: Juergen Gross, xen-devel, linux-input, linux-kernel, lyan,
boris.ostrovsky, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <8ef84389-4659-d4bb-271f-53155062b7b6@gmail.com>
On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote:
> On 04/23/2018 09:53 PM, Dmitry Torokhov wrote:
> > On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/19/2018 02:25 PM, Juergen Gross wrote:
> > > > On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
> > > > > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > > > >
> > > > > It is now only possible to control if multi-touch virtual device
> > > > > is created or not (via the corresponding XenStore entries),
> > > > > but keyboard and pointer devices are always created.
> > > > Why don't you want to go that route for keyboard and mouse, too?
> > > > Or does this really make no sense?
> > > Well, I would prefer not to touch anything outside Linux and
> > > this driver. And these settings seem to be implementation specific.
> > > So, this is why introduce Linux module parameters and don't extend
> > > the kbdif protocol.
> > Why do you consider this implementation specific? How other guests
> > decide to forego creation of relative pointer device or keyboard-like
> > device?
> >
> > You already have "features" for absolute pointing device and multitouch,
> > so please extend the protocol properly so you indeed do not code
> > something implementation-specific (i.e. module parameters).
> Ok, but in order to preserve the default behavior, e.g.
> pointer and keyboard devices are always created now, I'll have
> to have reverse features in the protocol:
> - feature-no-pointer
> - feature-no-keyboard
> The above may be set as a part of frontend's configuration and
> if missed are considered to be set to false.
I think you can have them as "feature-pointer" and "feature-keyboard"
(no negation), but assume not present considered enabled. I.e.
kbd = xenbus_read_unsigned(..., XENKBD_FIELD_FEAT_KEYBOARD, 1);
if (kbd) {
...
}
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.
From: Dmitry Torokhov @ 2018-04-26 16:42 UTC (permalink / raw)
To: Guenter Roeck
Cc: Vittorio Gambaletta (VittGam), linux-kernel, linux-input,
# v4 . 10+, nick, Benson Leung, Salvatore Bellizzi, Guenter Roeck
In-Reply-To: <CABXOdTeh3yLtsWxUCWFdpQNQReAmVDnuJh+T07X=YB3dq=uG1Q@mail.gmail.com>
On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote:
> On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) <
> linuxbugs@vittgam.net> wrote:
>
> > Hello,
> >
> > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote:
> > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote:
> > >> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam)
> > wrote:
> > >> > This patch adds the correct platform data information for the Caroline
> > >> > Chromebook, so that the mouse button does not get stuck in pressed
> > state
> > >> > after the first click.
> > >> >
> > >> > The Samus button keymap and platform data definition are the correct
> > >> > ones for Caroline, so they have been reused here.
> > >> >
> > >> > v2: updated patch offset after 20180409 changes.
> > >> >
> > >> > Cc: stable@vger.kernel.org
> > >> > Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> > >> > Signed-off-by: Salvatore Bellizzi <lkml@seppia.net>
> > >> >
> > >>
> > >> Applied, thank you.
> > >>
> > >> > ---
> > >> >
> > >> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > >> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > >> > @@ -3035,6 +3035,15 @@
> > >> > .driver_data = samus_platform_data,
> > >> > },
> > >> > {
> > >> > + /* Samsung Chromebook Pro */
> > >> > + .ident = "Samsung Chromebook Pro",
> > >> > + .matches = {
> > >> > + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> > >
> > > I've been alerted that shipping BIOS has vendor not capitalized; where
> > > did you get the firmware that has vendor all capitals?
> >
> > Upstream coreboot and mrchromebox's coreboot, which do support loading
> > Linux
> > natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor
> > as far as I know.
> >
> > By the way, the shipping BIOS (coreboot customized by Google) does not
> > support
> > mainline Linux natively (eg. without seabios and nasty tricks), but only
> > Chromium OS, which for Caroline is an old 3.something fork of Linux, so
> > this
> > patch does not really apply to Chromium OS or to Linux running on shipping
> > BIOS.
> >
> > Can you provide details or a pointer to it ? The mainline kernel boots
> fine for me (with a ChromeOS distribution), with the exception of the
> Google/GOOGLE problem.
>
>
> > Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in
> > Google's coreboot for Caroline too, but I'm not 100% sure and cannot check
> > right now.
> >
> >
> FWIW, the DMI system vendor is "Google" in my Caroline. I'll dig up
> configuration files later today - maybe it was changed to "GOOGLE" at some
> point and I have an old Bios in my system.
I believe all shipping BIOSes use "Google" as vendor, as it is what is
specified in src/mainboard/google/Kconfig::MAINBOARD_VENDOR and our
configs/build scripts do not override it.
I do not know why we have this difference.
>
> Thanks,
> Guenter
>
> By the way please note that this is the DMI System Vendor and not the DMI
> > BIOS version string, which indeed starts with "Google_" in the shipping
> > BIOS
> > (but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd).
Hmm, I just tried checking out tree from
https://review.coreboot.org/coreboot.git and do not see this commit:
dtor@dtor-ws:~/coreboot $ git show f56db262e46d3368ee4e5c9e19797853cab382cd
fatal: bad object f56db262e46d3368ee4e5c9e19797853cab382cd
dtor@dtor-ws:~/coreboot $ git log --oneline -1 HEAD
82d0f91420 (HEAD -> master, origin/master, origin/HEAD) soc/intel/apollolake: enable exception handling in every stage for glk
Anyway, if you are overriding the shipping BIOS, then please adjust
coreboot to use device-tree compatible bindings (via PRP0001 HID and
_DSD properties - you can check out bindings for PENH device in Caroline
to see how they can be used). This way we would not need to breed DMI
quirks.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] hid: intel-ish-hid: use put_device() instead of kfree()
From: Jiri Kosina @ 2018-04-26 12:37 UTC (permalink / raw)
To: Arvind Yadav
Cc: srinivas.pandruvada, benjamin.tissoires, linux-kernel,
linux-input
In-Reply-To: <66bd5f1ab1322081927f657090a04b44da326140.1522408033.git.arvind.yadav.cs@gmail.com>
On Fri, 30 Mar 2018, Arvind Yadav wrote:
> Never directly free @dev after calling device_register(), even
> if it returned an error. Always use put_device() to give up the
> reference initialized.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox