* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Christopher Lameter @ 2018-09-27 14:16 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Dmitry Torokhov, syzbot+87829a10073277282ad1, Pekka Enberg,
linux-input@vger.kernel.org, lkml, Henrik Rydberg, syzkaller-bugs,
Linux-MM
In-Reply-To: <CACT4Y+aUdAmRmgiV5-KWXF-eGoCUCMhUC+ddLU-heQTQ53PhRA@mail.gmail.com>
On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <cl@linux.com> wrote:
> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
> >
> >> Assuming that the size is large enough to fail in all allocators, is
> >> this warning still useful? How? Should we remove it?
> >
> > Remove it. It does not make sense because we check earlier if possible
> > without the warn.
>
> Mailed "mm: don't warn about large allocations for slab" to remove the warning.
>
Hoe it arrives here at some point.
^ permalink raw reply
* [PATCH] HID: elan: fix spelling mistake "registred" -> "registered"
From: Colin King @ 2018-09-27 14:00 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in hid_err error message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/hid/hid-elan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-elan.c b/drivers/hid/hid-elan.c
index 07e26c3567eb..0bfd6d1b44c1 100644
--- a/drivers/hid/hid-elan.c
+++ b/drivers/hid/hid-elan.c
@@ -497,7 +497,7 @@ static int elan_probe(struct hid_device *hdev, const struct hid_device_id *id)
return 0;
if (!drvdata->input) {
- hid_err(hdev, "Input device is not registred\n");
+ hid_err(hdev, "Input device is not registered\n");
ret = -ENAVAIL;
goto err;
}
--
2.17.1
^ permalink raw reply related
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Dmitry Vyukov @ 2018-09-27 13:07 UTC (permalink / raw)
To: Christopher Lameter
Cc: Dmitry Torokhov, syzbot+87829a10073277282ad1, Pekka Enberg,
linux-input@vger.kernel.org, lkml, Henrik Rydberg, syzkaller-bugs,
Linux-MM
In-Reply-To: <01000166110bb882-0b1fa048-fe1c-4139-a1ba-702754bbc267-000000@email.amazonses.com>
On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <cl@linux.com> wrote:
> On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
>
>> Assuming that the size is large enough to fail in all allocators, is
>> this warning still useful? How? Should we remove it?
>
> Remove it. It does not make sense because we check earlier if possible
> without the warn.
Mailed "mm: don't warn about large allocations for slab" to remove the warning.
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: input: pwm-vibrator: correct pwms in example
From: Sebastian Reichel @ 2018-09-27 6:45 UTC (permalink / raw)
To: Brian Masney
Cc: robh, dmitry.torokhov, linux-input, devicetree, linux-kernel,
mark.rutland
In-Reply-To: <20180927004858.32529-1-masneyb@onstation.org>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
Hi,
On Wed, Sep 26, 2018 at 08:48:58PM -0400, Brian Masney wrote:
> In the example for the pwm-vibrator bindings, pwm8 is the direction pin,
> and pwm9 is the enable pin. The pwms on the vibrator node has these two
> values swapped so this patch corrects it.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> ---
>
> Changes since v1:
> - Swapped the pwms values instead of the pwm-names values since enable
> is required and direction is optional. Based on feedback from
> Rob Herring.
>
> Documentation/devicetree/bindings/input/pwm-vibrator.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> index 09145d18491d..88c775a3fe21 100644
> --- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> @@ -58,8 +58,8 @@ Example from Motorola Droid 4:
>
> vibrator {
> compatible = "pwm-vibrator";
> - pwms = <&pwm8 0 1000000000 0>,
> - <&pwm9 0 1000000000 0>;
> + pwms = <&pwm9 0 1000000000 0>,
> + <&pwm8 0 1000000000 0>;
> pwm-names = "enable", "direction";
> direction-duty-cycle-ns = <1000000000>;
> };
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] dt-bindings: input: pwm-vibrator: correct pwms in example
From: Brian Masney @ 2018-09-27 0:48 UTC (permalink / raw)
To: robh, dmitry.torokhov, linux-input, devicetree, linux-kernel,
sebastian.reichel, mark.rutland
Cc: masneyb
In the example for the pwm-vibrator bindings, pwm8 is the direction pin,
and pwm9 is the enable pin. The pwms on the vibrator node has these two
values swapped so this patch corrects it.
Signed-off-by: Brian Masney <masneyb@onstation.org>
---
Changes since v1:
- Swapped the pwms values instead of the pwm-names values since enable
is required and direction is optional. Based on feedback from
Rob Herring.
Documentation/devicetree/bindings/input/pwm-vibrator.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
index 09145d18491d..88c775a3fe21 100644
--- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt
+++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
@@ -58,8 +58,8 @@ Example from Motorola Droid 4:
vibrator {
compatible = "pwm-vibrator";
- pwms = <&pwm8 0 1000000000 0>,
- <&pwm9 0 1000000000 0>;
+ pwms = <&pwm9 0 1000000000 0>,
+ <&pwm8 0 1000000000 0>;
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <1000000000>;
};
--
2.17.1
^ permalink raw reply related
* Re: hid: microsoft: Add rumble support for Xbox One S controller
From: Florian Dollinger @ 2018-09-26 22:50 UTC (permalink / raw)
To: Bastien Nocera, andrew.smirnov
Cc: linux-kernel, linux-bluetooth@vger.kernel.org, linux-input
In-Reply-To: <75590dbdffee5870537a344209af185cdda5de30.camel@hadess.net>
> Sure it is, but:
> - it's not an "XBox One S controller", it's a variant of the "XBox One
> controller" shipped with the XBox One S.
> - we discussed this on the linux-bluetooth mailing-list in August 2016:
> https://www.spinics.net/lists/linux-bluetooth/msg68102.html
> revived the thread in 2017:
> https://www.spinics.net/lists/linux-bluetooth/msg72750.html
> and discussed the force feedback in particular in August this year:
> https://www.spinics.net/lists/linux-input/msg57744.html
> - why would we look for a "driver" when there's already one in the
> kernel that supports all the xbox controllers except this one? :)
>
> Really, as much as it's nice to find working code for this device, it's
> surprising you didn't contact any kernel developer before, rather than
> us having to find you.
Fair enough :)
> Yes, but that's not the way the drivers are usually arranged. They're
> arranged by vendors, so this driver would need to be merged into the
> "hid-microsoft.c" driver.
That's probably the main reason for not getting in touch earlier, I
really don't like the idea of putting everything into the same driver
just because it is the same vendor - or at leas the same name (even if
Microsoft Xbox has nearly nothing to do with other parts of Microsoft).
> I'm pretty sure that the USB version can also be made to use HID.
I really don't think so, I already gave it a try. At least not "out of
the box".
> I have no idea how the RF protocol would work though. I imagine it
> requires a dongle, or does it actually use Wi-Fi? (that would be
> surprising...).
In theory it does need one, but it is nothing more than normal Wi-Fi
(2,4 and 5 GHz) - you can talk to the gamepad using any Wi-Fi card /
stick you want. The problem is, that the connection is secured somehow.
If you are interested, take a look here:
https://github.com/atar-axis/xpadneo/wiki/Microsoft-Xbox-One-Wireless-Adapter
> Anyway, I don't have much time to work on it right this minute, but it
> would be great if you could send your Bluetooth patch to start with,
> and we can iterate on that, and fix the other problems as we clear the
> priority list.
Jap, I will do that - Thank you so far!
> Cheers
Dito.
^ permalink raw reply
* Re: XBox One S controller, Bluetooth support (was Re: hid: microsoft: Add rumble support for Xbox One S controller)
From: Florian Dollinger @ 2018-09-26 22:35 UTC (permalink / raw)
To: Bastien Nocera, andrew.smirnov
Cc: linux-kernel, linux-bluetooth@vger.kernel.org, linux-input
In-Reply-To: <b455a236b677c03f623ddbd5c28e602def439bc9.camel@hadess.net>
> For this patch, after speaking with the Bluetooth maintainers, we would
> need to:
> - add relevant btmon outputs before and after the patch in the commit
> message
> - remove the mention of "many devices" (if you've seen other devices
> with that problem in the wild, please mention them, otherwise mention
> that it's for "XBox One S" controllers, and clones)
> - run the patch against the "Profile Tuning Suite Tool" from the
> Bluetooth SIG. This requires a Windows laptop, and a piece of hardware
> from the Bluetooth SIG, see below.
>
> The first 2 should be pretty easy to do, just send your patch using
> "git send-email" to the linux-bluetooth list (CC:ed), with the data
> attached.
>
> For the qualification test, I was told Szymon has a test suite that he
> could use to double-check the tests. If not, I should be able to buy
> the adapter and run that test suite locally.
>
> Cheers
Thanks, I will give it a try tomorrow (later) :)
^ permalink raw reply
* Re: AW: hid: microsoft: Add rumble support for Xbox One S controller
From: Bastien Nocera @ 2018-09-26 18:02 UTC (permalink / raw)
To: dollinger.florian, andrew.smirnov
Cc: linux-kernel, linux-bluetooth@vger.kernel.org, linux-input
In-Reply-To: <003401d455ab$c6df5280$549df780$@gmx.de>
On Wed, 2018-09-26 at 17:15 +0200, dollinger.florian@gmx.de wrote:
> Hey Bastien,
>
> > Probably because he didn't know about it, and how would he?
>
> Hum, it's the first hit when you search for something like 'xbox one
> s driver linux' since half an year or longer 😊
Sure it is, but:
- it's not an "XBox One S controller", it's a variant of the "XBox One
controller" shipped with the XBox One S.
- we discussed this on the linux-bluetooth mailing-list in August 2016:
https://www.spinics.net/lists/linux-bluetooth/msg68102.html
revived the thread in 2017:
https://www.spinics.net/lists/linux-bluetooth/msg72750.html
and discussed the force feedback in particular in August this year:
https://www.spinics.net/lists/linux-input/msg57744.html
- why would we look for a "driver" when there's already one in the
kernel that supports all the xbox controllers except this one? :)
Really, as much as it's nice to find working code for this device, it's
surprising you didn't contact any kernel developer before, rather than
us having to find you.
> > I can imagine that a large portion of the driver can be integrated
> > in the existing XBox pad driver, with each feature added in
> > individual patches.
>
> Would be great! But ist the xpad driver really the right place?
>
> First of all, the BT interface is using HID, USB does not.
> Furthermore, the driver is currently around 1,3k lines long - for a
> single device and only BT... (okay yes, there are a lot of comments
> in it).
> But anyway, is it really a good idea to put everything into hid-
> microsoft?
> Moreover, there is another interface which I am trying to support at
> the moment - the one which is used by the XBOX (WiFi).
>
> I think in the end the whole hid-microsoft thingy will get blown-up a
> bit - right?
> Or, everything is scattered over many places (hid-microsoft, xpad,
> another driver fort he wifi-interface).
>
> Isn't it possible to use "one driver per device" in the kernel too,
> like I did?
Yes, but that's not the way the drivers are usually arranged. They're
arranged by vendors, so this driver would need to be merged into the
"hid-microsoft.c" driver.
I'm pretty sure that the USB version can also be made to use HID.
I have no idea how the RF protocol would work though. I imagine it
requires a dongle, or does it actually use Wi-Fi? (that would be
surprising...).
Anyway, I don't have much time to work on it right this minute, but it
would be great if you could send your Bluetooth patch to start with,
and we can iterate on that, and fix the other problems as we clear the
priority list.
Cheers
^ permalink raw reply
* XBox One S controller, Bluetooth support (was Re: hid: microsoft: Add rumble support for Xbox One S controller)
From: Bastien Nocera @ 2018-09-26 17:43 UTC (permalink / raw)
To: Dollinger Florian, andrew.smirnov
Cc: linux-kernel, linux-bluetooth@vger.kernel.org, linux-input
In-Reply-To: <701e5f0fc3b24adf4b1ca4d817b3091fe73102ba.camel@hadess.net>
(Resend to the correct Bluetooth list, sorry for the dupes)
On Wed, 2018-09-26 at 15:45 +0200, Bastien Nocera wrote:
> Hey Florian,
>
> On Wed, 2018-09-26 at 14:51 +0200, Dollinger Florian wrote:
> > From: Florian Dollinger <dollinger.florian@gmx.de>
> >
> > Hi there! Why do you re-engineer the wheel? :) There is already a
> > fully functional and tested driver out there (
> > https://github.com/atar-axis/xpadneo). Would be much easier to help
> > me (the owner of xpadneo) to push it into the kernel.
>
> Probably because he didn't know about it, and how would he? I also
> didn't know about it, because it didn't exist last I worked on those
> joypads.
>
> I spent quite a bit of time trying to get the XBox One S controller
> working over Bluetooth, without success, and I see that you have a
> patch for that which you didn't send upstream either:
>
https://github.com/atar-axis/xpadneo/blob/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
For this patch, after speaking with the Bluetooth maintainers, we would
need to:
- add relevant btmon outputs before and after the patch in the commit
message
- remove the mention of "many devices" (if you've seen other devices
with that problem in the wild, please mention them, otherwise mention
that it's for "XBox One S" controllers, and clones)
- run the patch against the "Profile Tuning Suite Tool" from the
Bluetooth SIG. This requires a Windows laptop, and a piece of hardware
from the Bluetooth SIG, see below.
The first 2 should be pretty easy to do, just send your patch using
"git send-email" to the linux-bluetooth list (CC:ed), with the data
attached.
For the qualification test, I was told Szymon has a test suite that he
could use to double-check the tests. If not, I should be able to buy
the adapter and run that test suite locally.
Cheers
^ permalink raw reply
* XBox One S controller, Bluetooth support (was Re: hid: microsoft: Add rumble support for Xbox One S controller)
From: Bastien Nocera @ 2018-09-26 16:09 UTC (permalink / raw)
To: Dollinger Florian, andrew.smirnov
Cc: linux-kernel, linux-bluetooth, linux-input
In-Reply-To: <701e5f0fc3b24adf4b1ca4d817b3091fe73102ba.camel@hadess.net>
On Wed, 2018-09-26 at 15:45 +0200, Bastien Nocera wrote:
> Hey Florian,
>
> On Wed, 2018-09-26 at 14:51 +0200, Dollinger Florian wrote:
> > From: Florian Dollinger <dollinger.florian@gmx.de>
> >
> > Hi there! Why do you re-engineer the wheel? :) There is already a
> > fully functional and tested driver out there (
> > https://github.com/atar-axis/xpadneo). Would be much easier to help
> > me (the owner of xpadneo) to push it into the kernel.
>
> Probably because he didn't know about it, and how would he? I also
> didn't know about it, because it didn't exist last I worked on those
> joypads.
>
> I spent quite a bit of time trying to get the XBox One S controller
> working over Bluetooth, without success, and I see that you have a
> patch for that which you didn't send upstream either:
> https://github.com/atar-axis/xpadneo/blob/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
For this patch, after speaking with the Bluetooth maintainers, we would
need to:
- add relevant btmon outputs before and after the patch in the commit
message
- remove the mention of "many devices" (if you've seen other devices
with that problem in the wild, please mention them, otherwise mention
that it's for "XBox One S" controllers, and clones)
- run the patch against the "Profile Tuning Suite Tool" from the
Bluetooth SIG. This requires a Windows laptop, and a piece of hardware
from the Bluetooth SIG, see below.
The first 2 should be pretty easy to do, just send your patch using
"git send-email" to the linux-bluetooth list (CC:ed), with the data
attached.
For the qualification test, I was told Szymon has a test suite that he
could use to double-check the tests. If not, I should be able to buy
the adapter and run that test suite locally.
Cheers
^ permalink raw reply
* Re: [PATCH V2 7/8] dt-bindings: watchdog: document stpmic1 pmic watchdog
From: Rob Herring @ 2018-09-26 15:29 UTC (permalink / raw)
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
Pascal PAILLET-LME
In-Reply-To: <1536325173-16617-8-git-send-email-p.paillet@st.com>
On Fri, 7 Sep 2018 12:59:45 +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> The stpmic1 PMIC embeds a watchdog which is disabled by default.
> In case of watchdog, the PMIC goes off.
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: hid: microsoft: Add rumble support for Xbox One S controller
From: dollinger.florian @ 2018-09-26 15:23 UTC (permalink / raw)
To: 'Bastien Nocera', andrew.smirnov
Cc: linux-kernel, linux-input-owner, linux-input
Hey Bastien,
> Probably because he didn't know about it, and how would he?
Hum, it's the first hit when you search for something like 'xbox one s driver linux' since half an year or longer 😊
> I spent quite a bit of time trying to get the XBox One S controller working over Bluetooth, without success, and I see that you have a patch for that which you didn't send upstream either:
https://github.com/atar-axis/xpadneo/blob/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
Jap, I just never pushed it because I never pushed anything to the linux kernel and I don't really know how the whole process works^^ Furthermore I wanted to fix possible before, but it looks like the driver is stable enough to push it now.
> I can imagine that a large portion of the driver can be integrated in the existing XBox pad driver, with each feature added in individual patches.
Would be great! But ist the xpad driver really the right place?
First of all, the BT interface is using HID, USB does not.
Furthermore, the driver is currently around 1,3k lines long - for a single device and only BT... (okay yes, there are a lot of comments in it).
But anyway, is it really a good idea to put everything into hid-microsoft?
Moreover, there is another interface which I am trying to support at the moment - the one which is used by the XBOX (WiFi).
I think in the end the whole hid-microsoft thingy will get blown-up a bit - right?
Or, everything is scattered over many places (hid-microsoft, xpad, another driver fort he wifi-interface).
Isn't it possible to use "one driver per device" in the kernel too, like I did?
> If I get the time, there are good chances I will send a patch to integrate the battery reporting in the existing driver at least, and then add support for missing buttons if there's a problem there (I see that mentioned in the README).
Jap, the wrong mapping is possibly the biggest problem of all. Battery support and FF is more "nice to have" but not really crucial.
> "Trigger Force Feedback" is likely something that would need to be integrated at a lower level, this is probably not something we'd want to have replicated in each driver.
True.
Best regards, Flo
^ permalink raw reply
* AW: hid: microsoft: Add rumble support for Xbox One S controller
From: dollinger.florian @ 2018-09-26 15:15 UTC (permalink / raw)
To: 'Bastien Nocera', andrew.smirnov
Cc: linux-kernel, linux-input-owner, linux-input
In-Reply-To: <701e5f0fc3b24adf4b1ca4d817b3091fe73102ba.camel@hadess.net>
Hey Bastien,
> Probably because he didn't know about it, and how would he?
Hum, it's the first hit when you search for something like 'xbox one s driver linux' since half an year or longer 😊
> I spent quite a bit of time trying to get the XBox One S controller working over Bluetooth, without success, and I see that you have a patch for that which you didn't send upstream either:
https://github.com/atar-axis/xpadneo/blob/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
Jap, I just never pushed it because I never pushed anything to the linux kernel and I don't really know how the whole process works^^
Furthermore I wanted to fix possible before, but it looks like the driver is stable enough to push it now.
> I can imagine that a large portion of the driver can be integrated in the existing XBox pad driver, with each feature added in individual patches.
Would be great! But ist the xpad driver really the right place?
First of all, the BT interface is using HID, USB does not.
Furthermore, the driver is currently around 1,3k lines long - for a single device and only BT... (okay yes, there are a lot of comments in it).
But anyway, is it really a good idea to put everything into hid-microsoft?
Moreover, there is another interface which I am trying to support at the moment - the one which is used by the XBOX (WiFi).
I think in the end the whole hid-microsoft thingy will get blown-up a bit - right?
Or, everything is scattered over many places (hid-microsoft, xpad, another driver fort he wifi-interface).
Isn't it possible to use "one driver per device" in the kernel too, like I did?
> If I get the time, there are good chances I will send a patch to integrate the battery reporting in the existing driver at least, and then add support for missing buttons if there's a problem there (I see that mentioned in the README).
Jap, the wrong mapping is possibly the biggest problem of all. Battery support and FF is more "nice to have" but not really crucial.
> "Trigger Force Feedback" is likely something that would need to be integrated at a lower level, this is probably not something we'd want to have replicated in each driver.
True.
Best regards, Flo
^ permalink raw reply
* Re: hid: microsoft: Add rumble support for Xbox One S controller
From: Bastien Nocera @ 2018-09-26 13:45 UTC (permalink / raw)
To: Dollinger Florian, andrew.smirnov
Cc: linux-kernel, linux-input-owner, linux-input
In-Reply-To: <20180926125130.974-1-dollinger.florian@gmx.de>
Hey Florian,
On Wed, 2018-09-26 at 14:51 +0200, Dollinger Florian wrote:
> From: Florian Dollinger <dollinger.florian@gmx.de>
>
> Hi there! Why do you re-engineer the wheel? :) There is already a
> fully functional and tested driver out there (
> https://github.com/atar-axis/xpadneo). Would be much easier to help
> me (the owner of xpadneo) to push it into the kernel.
Probably because he didn't know about it, and how would he? I also
didn't know about it, because it didn't exist last I worked on those
joypads.
I spent quite a bit of time trying to get the XBox One S controller
working over Bluetooth, without success, and I see that you have a
patch for that which you didn't send upstream either:
https://github.com/atar-axis/xpadneo/blob/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
I can imagine that a large portion of the driver can be integrated in
the existing XBox pad driver, with each feature added in individual
patches.
If I get the time, there are good chances I will send a patch to
integrate the battery reporting in the existing driver at least, and
then add support for missing buttons if there's a problem there (I see
that mentioned in the README).
"Trigger Force Feedback" is likely something that would need to be
integrated at a lower level, this is probably not something we'd want
to have replicated in each driver.
Cheers
^ permalink raw reply
* Re: hid: microsoft: Add rumble support for Xbox One S controller
From: Dollinger Florian @ 2018-09-26 12:51 UTC (permalink / raw)
To: andrew.smirnov
Cc: linux-kernel, linux-input-owner, linux-input, Florian Dollinger
In-Reply-To: <20180810001714.14659-1-andrew.smirnov@gmail.com>
From: Florian Dollinger <dollinger.florian@gmx.de>
Hi there! Why do you re-engineer the wheel? :) There is already a fully functional and tested driver out there (https://github.com/atar-axis/xpadneo). Would be much easier to help me (the owner of xpadneo) to push it into the kernel.
^ permalink raw reply
* [PATCH] HID: elan: Make array buf static, shrinks object size
From: Colin King @ 2018-09-26 8:41 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array buf on the stack but instead make it
static. Makes the object code smaller by 43 bytes:
Before:
text data bss dec hex filename
7769 1520 0 9289 2449 drivers/hid/hid-elan.o
After:
text data bss dec hex filename
7662 1584 0 9246 241e drivers/hid/hid-elan.o
(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/hid/hid-elan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-elan.c b/drivers/hid/hid-elan.c
index 07e26c3567eb..05377eec2cb2 100644
--- a/drivers/hid/hid-elan.c
+++ b/drivers/hid/hid-elan.c
@@ -393,7 +393,7 @@ static int elan_start_multitouch(struct hid_device *hdev)
* This byte sequence will enable multitouch mode and disable
* mouse emulation
*/
- const unsigned char buf[] = { 0x0D, 0x00, 0x03, 0x21, 0x00 };
+ static const unsigned char buf[] = { 0x0D, 0x00, 0x03, 0x21, 0x00 };
unsigned char *dmabuf = kmemdup(buf, sizeof(buf), GFP_KERNEL);
if (!dmabuf)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2 5/8] dt-bindings: input: document stpmic1 pmic onkey
From: Rob Herring @ 2018-09-25 21:37 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com
In-Reply-To: <1536325173-16617-6-git-send-email-p.paillet@st.com>
On Fri, Sep 07, 2018 at 12:59:45PM +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> The stpmic1 pmic is able to manage an onkey button. It can be configured
> to shut-down the power supplies on a long key-press with an adjustable
> duration.
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> .../devicetree/bindings/input/st,stpmic1-onkey.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
>
> diff --git a/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt b/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
> new file mode 100644
> index 0000000..b0db90d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
> @@ -0,0 +1,31 @@
> +STMicroelectronics STPMIC1 Onkey
> +
> +Required properties:
> +
> +- compatible = "st,stpmic1-onkey";
> +- interrupt-parent: phandle to the parent interrupt controller
> +- interrupts: interrupt line to use
> +- interrupt-names = "onkey-falling", "onkey-rising"
> + onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic
> + onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic
> +
> +Optional properties:
> +
> +- st,onkey-pwroff-enabled: power off on long key-press
This can be implied by the presence of 'power-off-time-sec' or not.
> +- st,onkey-long-press-seconds: long key-press duration from 1 to 16s
> + (default 16s)
> +- st,onkey-clear-cc-flag: onkey is able power on after an
> + over-current shutdown event.
> +- st,onkey-pu-inactive: onkey pull up is not active
> +
> +Example:
> +
> +onkey {
> + compatible = "st,stpmic1-onkey";
> + interrupt-parent = <&pmic>;
> + interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
> + interrupt-names = "onkey-falling", "onkey-rising";
> + status = "okay";
Don't show status in examples.
> + st,onkey-pwroff-enabled;
> + st,onkey-long-press-seconds = <10>;
> +};
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH V2 3/8] dt-bindings: regulator: document stpmic1 pmic regulators
From: Rob Herring @ 2018-09-25 21:25 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com
In-Reply-To: <1536325173-16617-4-git-send-email-p.paillet@st.com>
On Fri, Sep 07, 2018 at 12:59:44PM +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> The STPMIC1 regulators supply power to the application processor as well as
> to the external system peripherals such as DDR, Flash memories and system
> devices.
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> changes in v2:
> * the hardware component has been renamed from stpmu1 to stpmic1 !
> * replace _ with - in properties name
> * remove deprecated regulator-compatible from the example
> Rob, the st,mask_reset name is taken from the data-sheet. I have modified the
> description. I hope there is no confusion with bit masking know.
>
> .../bindings/regulator/st,stpmic1-regulator.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> new file mode 100644
> index 0000000..a3f4762
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
> @@ -0,0 +1,68 @@
> +STMicroelectronics STPMIC1 Voltage regulators
> +
> +Regulator Nodes are optional depending on needs.
> +
> +Available Regulators in STPMIC1 device are:
> + - buck1 for Buck BUCK1
> + - buck2 for Buck BUCK2
> + - buck3 for Buck BUCK3
> + - buck4 for Buck BUCK4
> + - ldo1 for LDO LDO1
> + - ldo2 for LDO LDO2
> + - ldo3 for LDO LDO3
> + - ldo4 for LDO LDO4
> + - ldo5 for LDO LDO5
> + - ldo6 for LDO LDO6
> + - vref_ddr for LDO Vref DDR
> + - boost for Buck BOOST
> + - pwr_sw1 for VBUS_OTG switch
> + - pwr_sw2 for SW_OUT switch
> +
> +Switches are fixed voltage regulators with only enable/disable capability.
> +
> +Optional properties:
> +- st,mask-reset: mask reset for this regulator: the regulator configuration
> + is maintained during pmic reset.
State this is boolean.
> +- regulator-pull-down: enable high pull down
> + if not specified light pull down is used
> +- regulator-over-current-protection:
> + if set, all regulators are switched off in case of over-current detection
> + on this regulator,
> + if not set, the driver only sends an over-current event.
> +- interrupt-parent: phandle to the parent interrupt controller
This is implied. And actually not needed as the parent node is an
'interrupt-controller'.
> +- interrupts: index of current limit detection interrupt
> +- <regulator>-supply: phandle to the parent supply/regulator node
> + each regulator supply can be described except vref_ddr.
> +
> +Example:
> +regulators {
> + compatible = "st,stpmic1-regulators";
> +
> + ldo6-supply = <&v3v3>;
> +
> + vdd_core: buck1 {
> + regulator-name = "vdd_core";
> + interrupts = <IT_CURLIM_BUCK1 0>;
> + interrupt-parent = <&pmic>;
> + st,mask-reset;
> + regulator-pull-down;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1200000>;
> + };
> +
> + v3v3: buck4 {
> + regulator-name = "v3v3";
> + interrupts = <IT_CURLIM_BUCK4 0>;
> + interrupt-parent = <&mypmic>;
Different parent from buck1?
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + v1v8: ldo6 {
> + regulator-name = "v1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-over-current-protection;
> + };
> +};
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH V2 1/8] dt-bindings: mfd: document stpmic1
From: Rob Herring @ 2018-09-25 21:21 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com
In-Reply-To: <1536325173-16617-2-git-send-email-p.paillet@st.com>
On Fri, Sep 07, 2018 at 12:59:43PM +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> stpmic1 is a pmic from STMicroelectronics. The stpmic1 integrates 10
> regulators and 3 switches with various capabilities.
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> changes in v2:
> * the hardware component has been renamed from stpmu1 to stpmic1 !
> * replace _ with - in properties name
> * fix node names in example
> * remove regulator compatibles in example
> * add st,stpmic1.h to the patch
>
> Rob, I did not change the usage of the properties because it would lead to a lot
> of st properties; for example st,main-control-register would be replaced by:
> st,power_cycling_on_turn_off
> st,pwrctrl_enabled
> st,pwrctrl_active_high
> should I go this way ?
I guess it is fine as-is.
> Rob, I did not found the standard property for st,onkey-press-seconds = <10>;
>From input/keys.txt:
Optional properties for Keys:
- power-off-time-sec: Duration in seconds which the key should be kept
pressed for device to power off automatically. Device with key
pressed
shutdown feature can specify this property.
>
> .../devicetree/bindings/mfd/st,stpmic1.txt | 137 +++++++++++++++++++++
> include/dt-bindings/mfd/st,stpmic1.h | 46 +++++++
> 2 files changed, 183 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> new file mode 100644
> index 0000000..9f2c516
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> @@ -0,0 +1,137 @@
> +* STMicroelectronics STPMIC1 Power Management IC
> +
> +Required parent device properties:
> +- compatible: "st,stpmic1"
> +- reg: the I2C slave address for the stpmic1 chip
> +- interrupts-extended: interrupt lines to use: second irq is for wakeup.
Just use 'interrupts' here. Support for interrupts-extended is implied.
> +- #interrupt-cells: should be 2.
> +- interrupt-controller: describes the STPMIC1 as an interrupt
> + controller (has its own domain). interrupt number are the following:
> + /* Interrupt Register 1 (0x50 for latch) */
> + IT_SWOUT_R=0
> + IT_SWOUT_F=1
> + IT_VBUS_OTG_R=2
> + IT_VBUS_OTG_F=3
> + IT_WAKEUP_R=4
> + IT_WAKEUP_F=5
> + IT_PONKEY_R=6
> + IT_PONKEY_F=7
> + /* Interrupt Register 2 (0x51 for latch) */
> + IT_OVP_BOOST=8
> + IT_OCP_BOOST=9
> + IT_OCP_SWOUT=10
> + IT_OCP_OTG=11
> + IT_CURLIM_BUCK4=12
> + IT_CURLIM_BUCK3=13
> + IT_CURLIM_BUCK2=14
> + IT_CURLIM_BUCK1=15
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SHORT_SWOUT=16
> + IT_SHORT_SWOTG=17
> + IT_CURLIM_LDO6=18
> + IT_CURLIM_LDO5=19
> + IT_CURLIM_LDO4=20
> + IT_CURLIM_LDO3=21
> + IT_CURLIM_LDO2=22
> + IT_CURLIM_LDO1=23
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SWIN_R=24
> + IT_SWIN_F=25
> + IT_RESERVED_1=26
> + IT_RESERVED_2=27
> + IT_VINLOW_R=28
> + IT_VINLOW_F=29
> + IT_TWARN_R=30
> + IT_TWARN_F=31
> +
> +Optional parent device properties:
> +- st,main-control-register:
> + -bit 1: Power cycling will be performed on turn OFF condition
> + -bit 2: PWRCTRL is functional
> + -bit 3: PWRCTRL active high
> +- st,pads-pull-register:
> + -bit 1: WAKEUP pull down is not active
> + -bit 2: PWRCTRL pull up is active
> + -bit 3: PWRCTRL pull down is active
> + -bit 4: WAKEUP detector is disabled
> +- st,vin-control-register:
> + -bit 0: VINLOW monitoring is enabled
> + -bit [1...3]: VINLOW rising threshold
> + 000 VINOK_f + 50mV
> + 001 VINOK_f + 100mV
> + 010 VINOK_f + 150mV
> + 011 VINOK_f + 200mV
> + 100 VINOK_f + 250mV
> + 101 VINOK_f + 300mV
> + 110 VINOK_f + 350mV
> + 111 VINOK_f + 400mV
> + -bit [4...5]: VINLOW hyst
> + 00 100mV
> + 01 200mV
> + 10 300mV
> + 11 400mV
> + -bit 6: SW_OUT detector is disabled
> + -bit 7: SW_IN detector is enabled.
> +- st,usb-control-register:
> + -bit 3: SW_OUT current limit
> + 0: 600mA
> + 1: 1.1A
> + -bit 4: VBUS_OTG discharge is enabled
> + -bit 5: SW_OUT discharge is enabled
> + -bit 6: VBUS_OTG detection is enabled
> + -bit 7: BOOST_OVP is disabled
> +
> +
> +stpmic1 consists is a varied group of sub-devices:
> +
> +Device Description
> +------ ------------
> +st,stpmic1-onkey : On key
> +st,stpmic1-regulators : Regulators
> +st,stpmic1-wdt : Watchdog
> +
> +each sub-device bindings is be described in associated driver
> +documentation section.
> +
> +Example:
> +
> +pmic: stpmic1@33 {
pmic@33
> + compatible = "st,stpmic1";
> + reg = <0x33>;
> + interrupts = <0 2>;
> + interrupts-extended = <&intc GIC_SPI 149 IRQ_TYPE_NONE>,
> + <&exti 55 1>;
> + st,version_status = <0x10>;
> + st,main-control-register=<0x0c>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + onkey {
> + compatible = "st,stpmic1-onkey";
> + interrupt-parent = <&pmic>;
> + interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
> + interrupt-names = "onkey-falling", "onkey-rising";
> + st,onkey-pwroff-enabled;
> + st,onkey-long-press-seconds = <10>;
> + };
> +
> + watchdog {
> + compatible = "st,stpmic1-wdt";
> + };
> +
> + regulators {
> + compatible = "st,stpmic1-regulators";
> +
> + vdd_core: buck1 {
> + regulator-name = "vdd_core";
> + regulator-boot-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + vdd: buck3 {
> + regulator-name = "vdd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-pull-down;
> + };
> + };
> diff --git a/include/dt-bindings/mfd/st,stpmic1.h b/include/dt-bindings/mfd/st,stpmic1.h
> new file mode 100644
> index 0000000..e32ac8f
> --- /dev/null
> +++ b/include/dt-bindings/mfd/st,stpmic1.h
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
> + * Author: Philippe Peurichard <philippe.peurichard@st.com>,
> + * Pascal Paillet <p.paillet@st.com> for STMicroelectronics.
> + */
> +
> +#ifndef __DT_BINDINGS_STPMIC1_H__
> +#define __DT_BINDINGS_STPMIC1_H__
> +
> +/* IRQ definitions */
> +#define IT_PONKEY_F 0
> +#define IT_PONKEY_R 1
> +#define IT_WAKEUP_F 2
> +#define IT_WAKEUP_R 3
> +#define IT_VBUS_OTG_F 4
> +#define IT_VBUS_OTG_R 5
> +#define IT_SWOUT_F 6
> +#define IT_SWOUT_R 7
> +
> +#define IT_CURLIM_BUCK1 8
> +#define IT_CURLIM_BUCK2 9
> +#define IT_CURLIM_BUCK3 10
> +#define IT_CURLIM_BUCK4 11
> +#define IT_OCP_OTG 12
> +#define IT_OCP_SWOUT 13
> +#define IT_OCP_BOOST 14
> +#define IT_OVP_BOOST 15
> +
> +#define IT_CURLIM_LDO1 16
> +#define IT_CURLIM_LDO2 17
> +#define IT_CURLIM_LDO3 18
> +#define IT_CURLIM_LDO4 19
> +#define IT_CURLIM_LDO5 20
> +#define IT_CURLIM_LDO6 21
> +#define IT_SHORT_SWOTG 22
> +#define IT_SHORT_SWOUT 23
> +
> +#define IT_TWARN_F 24
> +#define IT_TWARN_R 25
> +#define IT_VINLOW_F 26
> +#define IT_VINLOW_R 27
> +#define IT_SWIN_F 30
> +#define IT_SWIN_R 31
> +
> +#endif /* __DT_BINDINGS_STPMIC1_H__ */
> --
> 1.9.1
^ permalink raw reply
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Christopher Lameter @ 2018-09-25 14:04 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Dmitry Torokhov, syzbot+87829a10073277282ad1, Pekka Enberg,
linux-input@vger.kernel.org, lkml, Henrik Rydberg, syzkaller-bugs,
Linux-MM
In-Reply-To: <CACT4Y+ZPrngv8GTC-Cw68PBDxZ2T5x1kKMNXL3DmP24Xd0m_5g@mail.gmail.com>
On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
> Assuming that the size is large enough to fail in all allocators, is
> this warning still useful? How? Should we remove it?
Remove it. It does not make sense because we check earlier if possible
without the warn.
^ permalink raw reply
* Re: [RFC/PATCH 2/5] device property: introduce notion of subnodes for legacy boards
From: Heikki Krogerus @ 2018-09-25 12:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rafael J . Wysocki, linux-input, linux-gpio,
linux-kernel, Andy Shevchenko
In-Reply-To: <20180924184543.GB156847@dtor-ws>
On Mon, Sep 24, 2018 at 11:45:43AM -0700, Dmitry Torokhov wrote:
> I think we are talking about totally different use cases and that is why
> we are having hard time coming to a mutually agreeable solution. Could
> you please describe in more detail what you would like to achieve,
> and preferably show how it is described now with DT and/or ACPI, so that
> I have a better frame of reference.
Yes, of course. Sorry.
USB ports are devices that usually the USB controller drivers register
(or actually the USB core code). They are represented in both ACPI and
DT as child nodes of the controller device node. The USB connector OF
node is defined in file
Documentation/devicetree/bindings/connector/usb-connector.txt
In short, the controller drivers will request handle to a child node
that represents a port, and only after that register the actual port
device.
The drivers I'm looking at currently are the USB Type-C port
controller drivers and the port manager (in Greg's usb-next or
linux-next):
drivers/usb/typec/tcpm/tcpci.c
drivers/usb/typec/tcpm/fusb302.c
drivers/usb/typec/tcpm/tcpm.c
The goal is simply to get rid of the platform data as usual, and
ideally so that we don't need any extra code in order to support the
"legacy" platforms.
Thanks,
--
heikki
^ permalink raw reply
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Dmitry Vyukov @ 2018-09-25 7:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Christopher Lameter, syzbot+87829a10073277282ad1, Pekka Enberg,
linux-input@vger.kernel.org, lkml, Henrik Rydberg, syzkaller-bugs,
Linux-MM
In-Reply-To: <20180924184158.GA156847@dtor-ws>
On Mon, Sep 24, 2018 at 8:41 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
>> On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
>>
>> > On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <cl@linux.com> wrote:
>> > > On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
>> > >
>> > >> What was the motivation behind that WARNING about large allocations in
>> > >> kmalloc? Why do we want to know about them? Is the general policy that
>> > >> kmalloc calls with potentially large size requests need to use NOWARN?
>> > >> If this WARNING still considered useful? Or we should change it to
>> > >> pr_err?
>> > >
>> > > In general large allocs should be satisfied by the page allocator. The
>> > > slab allocators are used for allocating and managing small objects. The
>> > > page allocator has mechanisms to deal with large objects (compound pages,
>> > > multiple page sized allocs etc).
>> >
>> > I am asking more about the status of this warning. If it fires in
>> > input_mt_init_slots(), does it mean that input_mt_init_slots() needs
>> > to be fixed? If not, then we need to change this warning to something
>> > else.
>>
>> Hmmm.. kmalloc falls back to the page allocator already?
>>
>> See
>>
>> static __always_inline void *kmalloc(size_t size, gfp_t flags)
>> {
>> if (__builtin_constant_p(size)) {
>
> It would not be a constant here though.
>
>> if (size > KMALLOC_MAX_CACHE_SIZE)
>> return kmalloc_large(size, flags);
>>
>>
>> Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
>> KMALLOC_MAX_SIZE.
>>
>>
>> How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
>> are larger than the maximum allowed by the page allocator. Thus the warning
>> and the NULL return.
>
> The size in this particular case is being derived from a value passed
> from userspace. Input core does not care about any limits on size of
> memory kmalloc() can support and is perfectly happy with getting NULL
> and telling userspace to go away with their silly requests by returning
> -ENOMEM.
>
> For the record: I definitely do not want to pre-sanitize size neither in
> uinput nor in input core.
Christopher,
Assuming that the size is large enough to fail in all allocators, is
this warning still useful? How? Should we remove it?
^ permalink raw reply
* Re: [PATCH] hyper-v: Fix wakeup from suspend-to-idle
From: Rafael J. Wysocki @ 2018-09-24 22:49 UTC (permalink / raw)
To: Jiri Kosina
Cc: Vitaly Kuznetsov, Linux PM, Rafael J. Wysocki, kys, haiyangz,
sthemmin, Dmitry Torokhov, linux-input, Linux Kernel Mailing List
In-Reply-To: <nycvar.YFH.7.76.1809241123040.15880@cbobk.fhfr.pm>
On Mon, Sep 24, 2018 at 11:24 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 12 Sep 2018, Vitaly Kuznetsov wrote:
>
> > It makes little sense but still possible to put Hyper-V guests into
> > suspend-to-idle state. To wake them up two wakeup sources were registered
> > in the past: hyperv-keyboard and hid-hyperv. However, since
> > commit eed4d47efe95 ("ACPI / sleep: Ignore spurious SCI wakeups from
> > suspend-to-idle") pm_wakeup_event() from these devices is ignored. Switch
> > to pm_wakeup_hard_event() API as these devices are actually the only
> > possible way to wakeup Hyper-V guests.
> >
> > Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
> > Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> > ---
> > drivers/hid/hid-hyperv.c | 2 +-
>
> Acked-by: Jiri Kosina <jkosina@suse.cz>
>
> for the above. I guess this'd better go through ACPI tree?
No problem with that if you prefer.
Cheers,
Rafael
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Arnd Bergmann @ 2018-09-24 21:17 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-pci,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Platform Driver,
sparclinux, driverdevel, linux-scsi,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, linux-rdma,
qat-linux-ral2JQCrhuEAvxtiuMwx3w,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
open list:HID CORE LAYER, Darren Hart, Linux Media Mailing List,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw, dri-devel, ceph-devel,
gregkh, USB list, linux-wireless
In-Reply-To: <20180924203505.GC6008-uk2M96/98Pc@public.gmane.org>
On Mon, Sep 24, 2018 at 10:35 PM Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
> On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote:
> > On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
> > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> > We already do this inside of some subsystems, notably drivers/media/,
> > and it simplifies the implementation of the ioctl handler function
> > significantly. We obviously cannot do this in general, both because of
> > traditional drivers that have 16-bit command codes (drivers/tty and others)
> > and also because of drivers that by accident defined the commands
> > incorrectly and use the wrong type or the wrong direction in the
> > definition.
>
> That could work well, but the first idea could be done globally and
> mechanically, while this would require very careful per-driver
> investigation.
>
> Particularly if the core code has worse performance.. ie due to
> kmalloc calls or something.
>
> I think it would make more sense to start by having the core do the
> case to __user and then add another entry point to have the core do
> the copy_from_user, and so on.
Having six separate callback pointers to implement a single
system call seems a bit excessive though.
Arnd
^ permalink raw reply
* Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
From: Jason Gunthorpe @ 2018-09-24 20:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Darren Hart, Al Viro, Linux FS-devel Mailing List, gregkh,
David Miller, driverdevel, Linux Kernel Mailing List, qat-linux,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
Linux Media Mailing List, dri-devel, linaro-mm-sig, amd-gfx,
open list:HID CORE LAYER, linux-iio, linux-rdma, linux-nvdimm,
linux-nvme, linux-pci
In-Reply-To: <CAK8P3a17GY89in7PeLk1F2T-0Xq=sCrwwntM+Y4BCpXheUC+qQ@mail.gmail.com>
On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> > > >
> > > > > Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
> > > > >
> > > > > As for a longer term solution, would it be possible to init fops in such
> > > > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> > > > > so we don't have to duplicate this boilerplate for every ioctl fops
> > > > > structure?
> > > >
> > > > Bad idea, that... Because several years down the road somebody will add
> > > > an ioctl that takes an unsigned int for argument. Without so much as looking
> > > > at your magical mystery macro being used to initialize file_operations.
> > >
> > > Fair, being explicit in the declaration as it is currently may be
> > > preferable then.
> >
> > It would be much cleaner and safer if you could arrange things to add
> > something like this to struct file_operations:
> >
> > long (*ptr_ioctl) (struct file *, unsigned int, void __user *);
> >
> > Where the core code automatically converts the unsigned long to the
> > void __user * as appropriate.
> >
> > Then it just works right always and the compiler will help address
> > Al's concern down the road.
>
> I think if we wanted to do this with a new file operation, the best
> way would be to do the copy_from_user()/copy_to_user() in the caller
> as well.
>
> We already do this inside of some subsystems, notably drivers/media/,
> and it simplifies the implementation of the ioctl handler function
> significantly. We obviously cannot do this in general, both because of
> traditional drivers that have 16-bit command codes (drivers/tty and others)
> and also because of drivers that by accident defined the commands
> incorrectly and use the wrong type or the wrong direction in the
> definition.
That could work well, but the first idea could be done globally and
mechanically, while this would require very careful per-driver
investigation.
Particularly if the core code has worse performance.. ie due to
kmalloc calls or something.
I think it would make more sense to start by having the core do the
case to __user and then add another entry point to have the core do
the copy_from_user, and so on.
Jason
^ 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