* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Dmitry Vyukov @ 2018-09-27 15:29 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: <010001661b9fad1d-cdbfabdb-5553-446f-bcde-585e42837415-000000@email.amazonses.com>
On Thu, Sep 27, 2018 at 5:22 PM, Christopher Lameter <cl@linux.com> wrote:
> On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
>
>> On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <cl@linux.com> wrote:
>> > 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.
>>
>> It's here:
>> https://lore.kernel.org/patchwork/patch/992660/
>>
>
> Please post on the mailing list
It is on the mailing lists:
https://lkml.org/lkml/2018/9/27/802
> and NAK to the patch. Testing against
> KMALLOC_MAX_CACHE_SIZE is not ok.
Why?
^ permalink raw reply
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Christopher Lameter @ 2018-09-27 15:22 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+biYtFUV7hK2ne2RfrbZjMt=4FK4deE0B6WykwT2qSt2g@mail.gmail.com>
On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <cl@linux.com> wrote:
> > 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.
>
> It's here:
> https://lore.kernel.org/patchwork/patch/992660/
>
Please post on the mailing list and NAK to the patch. Testing against
KMALLOC_MAX_CACHE_SIZE is not ok.
^ permalink raw reply
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Matthew Wilcox @ 2018-09-27 14:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Christopher Lameter, Dmitry Vyukov, 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 11:41:58AM -0700, Dmitry Torokhov wrote:
> > 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.
Probably should be using kvzalloc then.
^ permalink raw reply
* Re: WARNING: kmalloc bug in input_mt_init_slots
From: Dmitry Vyukov @ 2018-09-27 14:28 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: <010001661b631a3e-f398fc0a-127c-4c6e-b6ca-b2bd63bc4a9a-000000@email.amazonses.com>
On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <cl@linux.com> wrote:
> 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.
It's here:
https://lore.kernel.org/patchwork/patch/992660/
^ permalink raw reply
* 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
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