* Re: [PATCH] input_event: Provide override for sparc64
From: Deepa Dinamani @ 2019-01-16 0:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Arnd Bergmann, linux-input@vger.kernel.org, lkml,
y2038 Mailman List, David Miller
In-Reply-To: <CAKdAkRQdO14OP7SgE=D4x5RG7=cjDoCAOmtnCcWw_DrToeEmhA@mail.gmail.com>
> On Jan 15, 2019, at 2:32 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> On Tue, Jan 15, 2019 at 1:29 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Tue, 15 Jan 2019 22:19:27 +0100
>>
>>> The correct check appears to be
>>>
>>> #if defined(__sparc__) && defined(__arch64__)
>>
>> That is correct.
>
> OK. Deepa, could you please send me a fixup as I already pushed out
> the original patch?
Ok, I’m traveling. I will post an update in a couple of days.
Thanks,
Deepa
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Dmitry Torokhov @ 2019-01-15 22:32 UTC (permalink / raw)
To: Deepa Dinamani
Cc: y2038 Mailman List, David Miller, lkml, Arnd Bergmann,
linux-input@vger.kernel.org
In-Reply-To: <20190115.132928.900198180655535613.davem@davemloft.net>
On Tue, Jan 15, 2019 at 1:29 PM David Miller <davem@davemloft.net> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 15 Jan 2019 22:19:27 +0100
>
> > The correct check appears to be
> >
> > #if defined(__sparc__) && defined(__arch64__)
>
> That is correct.
OK. Deepa, could you please send me a fixup as I already pushed out
the original patch?
Thanks.
--
Dmitry
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: David Miller @ 2019-01-15 21:29 UTC (permalink / raw)
To: arnd; +Cc: y2038, linux-kernel, dmitry.torokhov, deepa.kernel, linux-input
In-Reply-To: <CAK8P3a1YG0+iMBiNy-g7KCusX3myV0tsuCEg1YLWW0cXrjk7PA@mail.gmail.com>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 15 Jan 2019 22:19:27 +0100
> The correct check appears to be
>
> #if defined(__sparc__) && defined(__arch64__)
That is correct.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Arnd Bergmann @ 2019-01-15 21:19 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, David Miller, y2038 Mailman List
In-Reply-To: <20181229183514.24644-1-deepa.kernel@gmail.com>
On Sat, Dec 29, 2018 at 7:35 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> struct timeval time;
> #define input_event_sec time.tv_sec
> #define input_event_usec time.tv_usec
> #else
> __kernel_ulong_t __sec;
> +#ifdef CONFIG_SPARC64
> + unsigned int __usec;
> +#else
> __kernel_ulong_t __usec;
> +#endif
> #define input_event_sec __sec
> #define input_event_usec __usec
> #endif
Sorry for not having looked at this earlier, I just realized that this
is a mistake
in user space: uapi headers are not allowed to reference CONFIG_* symbols,
since the headers are supposed to be configuration independent and the
CONFIG_* namespace might clash with user space identifiers.
The correct check appears to be
#if defined(__sparc__) && defined(__arch64__)
Arnd
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Rob Herring @ 2019-01-15 20:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Donghoon Han, linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190115035221.GA151157@dtor-ws>
On Mon, Jan 14, 2019 at 07:52:21PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> > Add DT binding document for rotary-encoder, keycode options.
> >
> > Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Cc: Daniel Mack <daniel@caiaq.de>
> > Cc: devicetree@vger.kernel.org
> > To: linux-input@vger.kernel.org
> > ---
> > .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > index f99fe5cdeaec..9986ec2af2d4 100644
> > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > @@ -12,6 +12,10 @@ Optional properties:
> > - rotary-encoder,relative-axis: register a relative axis rather than an
> > absolute one. Relative axis will only generate +1/-1 events on the input
> > device, hence no steps need to be passed.
> > +- rotary-encoder,relative-keys : generate pair of key events. This setting
> > + behaves just like relative-axis, generating key events instead.
> > + (Keycodes[2] corresponds to -1/1 events.)
> > +- rotary-encoder,relative-keycodes : keycodes for relative-keys
>
> Given that keycodes are linux-specific, I think the property should be
> linux,keycodes. Also, I am not sure we need separate
> rotary-encoder,relative-keys property as we can infer that we want to
> generate keys from presence of linux,keycodes property.
>
> Rob, any comments?
Yes, I had similar thoughts.
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Paul Menzel @ 2019-01-15 10:12 UTC (permalink / raw)
To: Benjamin Tissoires, Dmitry Torokhov; +Cc: Kim Phillips, LKML, linux-input
In-Reply-To: <CAO-hwJKCeV5ZEw7aX58=mnfhWex5QtEVYbRdDX7OosfS5+suUw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]
Dear Benjamin,
Thank you for chiming in.
On 01/15/19 09:57, Benjamin Tissoires wrote:
> On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote:
>>
>> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
>>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
>>>> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
>>>>> This patch is the result of seeing this message:
>>>>>
>>>>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
>>>>>
>>>>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
>>>>> smbus_pnp_ids, the touchpad continues to work, and the above message
>>>>> goes away, but we now get:
>>>>>
>>>>> psmouse serio1: synaptics: Trying to set up SMBus access
>>>>> psmouse serio1: synaptics: SMbus companion is not ready yet
>>>>>
>>>>> With this patch applied, i.e., the PNP IDs are added to the forcepad
>>>>> array, the touchpad continues to work and all of the above messages
>>>>> disappear.
>>>>
>>>> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
>>>> physical button underneath it)? As far as I know there were only couple
>>>> of HP laptops with forcepads and when switching to RMI mode forcepads
>>>> need F21 handler that we do not currently have in the kernel.
>>>
>>> I see, no, I'm not sure, but assuming you're right, the IDs
>>> should be added to the smbus array instead, after fixing
>>> the SMbus "companion not ready" problem? Pointers for that and
>>> the below interrupts when touchpad idle after resume, welcome.
>>>
>>> Also, the link to get the RMI4 spec in
>>> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>>> is broken. Any pointers for that also appreciated.
>>
>> OK, sorting it all out some more:
>>
>> - because we do not have support for F21 necessary for forcepads adding
>> APIC ID to forcepad list actuallty disables SMbus companion mode, that
>> is why you no longer see "companion not ready" messages vs. setting
>> psmouse.synaptics_intertouch=1 module parameter.
>
> Yep
>
>>
>> - this does not really matter as your touchpad ends up being driven by
>> i2c-hid and hid-multitouch drivers, and that is how we wait it to
>> work, as we do not want to deviate from behavior on Windows since OEM
>> tested it (the device and firmware) in tha configuration.
>
> Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
> wired at all, so we can't enable SMBus for them. Also, the fact that
> the device gets loaded over i2c-hid means that we can't know that it
> is the case from the psmouse/synaptics point of view.
>
>> - we need to figure out issue with interrupts on resume, maybe Benjamin
>> have seen it?
>
> First time I see it.
>
> I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was
> a problem.
I just wanted to clarify, that I am only able to reproduce the delay
during the *first* suspend/resume cycle. Subsequent tries are fine.
> I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
> also keeping firing the interrupts, but not the touchpad. However,
> here, the interrupts are not stopping when I touch the touchscreen or
> if I approach a pen.
>
> Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
> debug=1 doesn't show any events processed when the interrupts are
> firing. Do you see the same?
Kind regards,
Paul
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Benjamin Tissoires @ 2019-01-15 8:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Kim Phillips, lkml, Paul Menzel, open list:HID CORE LAYER
In-Reply-To: <20190114184012.GC117329@dtor-ws>
On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
> > On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> > > Hi Kim,
> >
> > Hi Dmitry,
> >
> > > On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
> > >> This patch is the result of seeing this message:
> > >>
> > >> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> > >>
> > >> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
> > >> smbus_pnp_ids, the touchpad continues to work, and the above message
> > >> goes away, but we now get:
> > >>
> > >> psmouse serio1: synaptics: Trying to set up SMBus access
> > >> psmouse serio1: synaptics: SMbus companion is not ready yet
> > >>
> > >> With this patch applied, i.e., the PNP IDs are added to the forcepad
> > >> array, the touchpad continues to work and all of the above messages
> > >> disappear.
> > >
> > > Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> > > physical button underneath it)? As far as I know there were only couple
> > > of HP laptops with forcepads and when switching to RMI mode forcepads
> > > need F21 handler that we do not currently have in the kernel.
> >
> > I see, no, I'm not sure, but assuming you're right, the IDs
> > should be added to the smbus array instead, after fixing
> > the SMbus "companion not ready" problem? Pointers for that and
> > the below interrupts when touchpad idle after resume, welcome.
> >
> > Also, the link to get the RMI4 spec in
> > Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> > is broken. Any pointers for that also appreciated.
>
> OK, sorting it all out some more:
>
> - because we do not have support for F21 necessary for forcepads adding
> APIC ID to forcepad list actuallty disables SMbus companion mode, that
> is why you no longer see "companion not ready" messages vs. setting
> psmouse.synaptics_intertouch=1 module parameter.
Yep
>
> - this does not really matter as your touchpad ends up being driven by
> i2c-hid and hid-multitouch drivers, and that is how we wait it to
> work, as we do not want to deviate from behavior on Windows since OEM
> tested it (the device and firmware) in tha configuration.
Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
wired at all, so we can't enable SMBus for them. Also, the fact that
the device gets loaded over i2c-hid means that we can't know that it
is the case from the psmouse/synaptics point of view.
>
> - we need to figure out issue with interrupts on resume, maybe Benjamin
> have seen it?
First time I see it.
I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem.
I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
also keeping firing the interrupts, but not the touchpad. However,
here, the interrupts are not stopping when I touch the touchscreen or
if I approach a pen.
Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
debug=1 doesn't show any events processed when the interrupts are
firing. Do you see the same?
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Dmitry Torokhov @ 2019-01-15 3:53 UTC (permalink / raw)
To: Donghoon Han, Rob Herring
Cc: linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190107164249.2342-3-nazgul33@gmail.com>
[ resending to Rob... ]
On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: devicetree@vger.kernel.org
> To: linux-input@vger.kernel.org
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..9986ec2af2d4 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
> absolute one. Relative axis will only generate +1/-1 events on the input
> device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events instead.
> + (Keycodes[2] corresponds to -1/1 events.)
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
Given that keycodes are linux-specific, I think the property should be
linux,keycodes. Also, I am not sure we need separate
rotary-encoder,relative-keys property as we can infer that we want to
generate keys from presence of linux,keycodes property.
Rob, any comments?
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = <&gpio 21 0>, <&gpio 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
> + };
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Dmitry Torokhov @ 2019-01-15 3:52 UTC (permalink / raw)
To: Donghoon Han; +Cc: linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190107164249.2342-3-nazgul33@gmail.com>
On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: devicetree@vger.kernel.org
> To: linux-input@vger.kernel.org
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..9986ec2af2d4 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
> absolute one. Relative axis will only generate +1/-1 events on the input
> device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events instead.
> + (Keycodes[2] corresponds to -1/1 events.)
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
Given that keycodes are linux-specific, I think the property should be
linux,keycodes. Also, I am not sure we need separate
rotary-encoder,relative-keys property as we can infer that we want to
generate keys from presence of linux,keycodes property.
Rob, any comments?
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = <&gpio 21 0>, <&gpio 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
> + };
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: dmitry.torokhov @ 2019-01-15 0:48 UTC (permalink / raw)
To: Lee Jones
Cc: Pascal PAILLET-LME, robh+dt@kernel.org, mark.rutland@arm.com,
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, axel.lin@ingics.com
In-Reply-To: <20181214124701.GZ4497@dell>
On Fri, Dec 14, 2018 at 12:47:01PM +0000, Lee Jones wrote:
> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
>
> > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> > STMicroelectronics.
> > The STPMIC1 regulators supply power to an application processor as well as
> > to external system peripherals such as DDR, Flash memories and system
> > devices. It also features onkey button input and an hardware watchdog.
> > The STPMIC1 is controlled via I2C.
> >
> > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> > as parent.
> >
> > STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> >
> > Pascal Paillet (7):
> > changes in v7:
> > * rebase on regul/for-next
> >
> > dt-bindings: mfd: document stpmic1
> > mfd: stpmic1: add stpmic1 driver
> > dt-bindings: input: document stpmic1 pmic onkey
> > input: stpmic1: add stpmic1 onkey driver
> > dt-bindings: watchdog: document stpmic1 pmic watchdog
> > watchdog: stpmic1: add stpmic1 watchdog driver
> > regulator: stpmic1: fix regulator_lock usage
>
> Could you please remove any patches which have been applied and
> [RESEND]?
>
> Also, is Dmitry planning on Acking:
>
> dt-bindings: input: document stpmic1 pmic onkey
>
> ... or is Rob's Ack enough?
For bindings I normally defer to Rob (unless I see something that really
bugs me and then I'll speak up).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/3] Input: atmel_mxt_ts: Wait for device be ready for communication
From: Dmitry Torokhov @ 2019-01-15 0:42 UTC (permalink / raw)
To: Paweł Chmiel
Cc: nick, robh+dt, mark.rutland, nicolas.ferre, alexandre.belloni,
linux-input, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20181214151214.5391-3-pawel.mikolaj.chmiel@gmail.com>
On Fri, Dec 14, 2018 at 04:12:13PM +0100, Paweł Chmiel wrote:
> According to documentation, device isn't ready for communication,
> until firmware asserts the CHG line. Add missing wait for this.
>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> Changes from v1:
> - Fix checkpatch issues
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 55a107fc1b73..e8949c6ceafa 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -202,6 +202,7 @@ enum t100_type {
> #define MXT_CRC_TIMEOUT 1000 /* msec */
> #define MXT_FW_RESET_TIME 3000 /* msec */
> #define MXT_FW_CHG_TIMEOUT 300 /* msec */
> +#define MXT_POWERON_DELAY 150 /* msec */
>
> /* Command to unlock bootloader */
> #define MXT_UNLOCK_CMD_MSB 0xaa
> @@ -3070,6 +3071,16 @@ static int mxt_regulator_enable(struct mxt_data *data)
> msleep(MXT_REGULATOR_DELAY);
> gpiod_set_value(data->reset_gpio, 1);
> msleep(MXT_RESET_INVALID_CHG);
> +
> +retry_wait:
> + reinit_completion(&data->bl_completion);
> + data->in_bootloader = true;
I think you would want to reinit the ocmpletion and set the flag before
releasing reset line and sleeping, otherwise if interrupt fires too
early you'll be spinning for extra time.
I'd also really want to hear from Nick on this change.
> + error = mxt_wait_for_completion(data, &data->bl_completion,
> + MXT_POWERON_DELAY);
> + if (error == -EINTR)
> + goto retry_wait;
> +
> + data->in_bootloader = false;
> }
>
> return 0;
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Peter Hutterer @ 2019-01-14 22:41 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
linux-kernel
In-Reply-To: <20190114220756.GF117329@dtor-ws>
On Mon, Jan 14, 2019 at 02:07:56PM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 14, 2019 at 02:04:48PM -0800, Dmitry Torokhov wrote:
> > An integer overflow may arise in uinput_validate_absinfo() if "max - min"
> > can't be represented by an "int". We should check for overflow before
> > trying to use the result.
> >
> > Reported-by: Kyungtae Kim <kt0755@gmail.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/input/misc/uinput.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> > index 8ec483e8688b..26ec603fe220 100644
> > --- a/drivers/input/misc/uinput.c
> > +++ b/drivers/input/misc/uinput.c
> > @@ -39,6 +39,7 @@
> > #include <linux/init.h>
> > #include <linux/fs.h>
> > #include <linux/miscdevice.h>
> > +#include <linux/overflow.h>
> > #include <linux/input/mt.h>
> > #include "../input-compat.h"
> >
> > @@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
> > static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> > const struct input_absinfo *abs)
> > {
> > - int min, max;
> > + int min, max, range;
> >
> > min = abs->minimum;
> > max = abs->maximum;
> > @@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> > return -EINVAL;
> > }
> >
> > - if (abs->flat > max - min) {
> > + if (check_sub_overflow(max, min, &range) && abs->flat > range) {
>
> This should be !check_sub_overflow(...) of course.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> with that in place,
thanks.
Cheers,
Peter
> > printk(KERN_DEBUG
> > "%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
> > UINPUT_NAME, code, abs->flat, min, max);
> > --
> > 2.20.1.97.g81188d93c3-goog
> >
> >
> > --
> > Dmitry
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Dmitry Torokhov @ 2019-01-14 22:07 UTC (permalink / raw)
To: linux-input
Cc: Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
Peter Hutterer, linux-kernel
In-Reply-To: <20190114220448.GA241112@dtor-ws>
On Mon, Jan 14, 2019 at 02:04:48PM -0800, Dmitry Torokhov wrote:
> An integer overflow may arise in uinput_validate_absinfo() if "max - min"
> can't be represented by an "int". We should check for overflow before
> trying to use the result.
>
> Reported-by: Kyungtae Kim <kt0755@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/misc/uinput.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 8ec483e8688b..26ec603fe220 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -39,6 +39,7 @@
> #include <linux/init.h>
> #include <linux/fs.h>
> #include <linux/miscdevice.h>
> +#include <linux/overflow.h>
> #include <linux/input/mt.h>
> #include "../input-compat.h"
>
> @@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
> static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> const struct input_absinfo *abs)
> {
> - int min, max;
> + int min, max, range;
>
> min = abs->minimum;
> max = abs->maximum;
> @@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> return -EINVAL;
> }
>
> - if (abs->flat > max - min) {
> + if (check_sub_overflow(max, min, &range) && abs->flat > range) {
This should be !check_sub_overflow(...) of course.
> printk(KERN_DEBUG
> "%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
> UINPUT_NAME, code, abs->flat, min, max);
> --
> 2.20.1.97.g81188d93c3-goog
>
>
> --
> Dmitry
--
Dmitry
^ permalink raw reply
* [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Dmitry Torokhov @ 2019-01-14 22:04 UTC (permalink / raw)
To: linux-input
Cc: Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
Peter Hutterer, linux-kernel
An integer overflow may arise in uinput_validate_absinfo() if "max - min"
can't be represented by an "int". We should check for overflow before
trying to use the result.
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/uinput.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 8ec483e8688b..26ec603fe220 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -39,6 +39,7 @@
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
+#include <linux/overflow.h>
#include <linux/input/mt.h>
#include "../input-compat.h"
@@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
const struct input_absinfo *abs)
{
- int min, max;
+ int min, max, range;
min = abs->minimum;
max = abs->maximum;
@@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
return -EINVAL;
}
- if (abs->flat > max - min) {
+ if (check_sub_overflow(max, min, &range) && abs->flat > range) {
printk(KERN_DEBUG
"%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
UINPUT_NAME, code, abs->flat, min, max);
--
2.20.1.97.g81188d93c3-goog
--
Dmitry
^ permalink raw reply related
* UBSAN: Undefined behaviour in drivers/input/misc/uinput.c
From: Kyungtae Kim @ 2019-01-14 21:19 UTC (permalink / raw)
To: Dmitry Torokhov, rydberg
Cc: Byoungyoung Lee, DaeRyong Jeong, syzkaller, linux-kernel,
linux-input
We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in
drivers/input/misc/uinput.c"
kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.c4925.c
An integer overflow arose in uinput_validate_absinfo
(drivers/input/misc/uinput.c:420).
To be specific, "if (abs->flat > max - min)" cannot be represented in
type 'int'.
Thing is, in this case, abs->flat, max and min come from user supplied input.
To fix, an appropriate sanity check of that calculation should be
placed right before the usage.
=========================================
UBSAN: Undefined behaviour in drivers/input/misc/uinput.c:420:22
signed integer overflow:
841280591 - -1832774988 cannot be represented in type 'int'
CPU: 0 PID: 7372 Comm: syz-executor3 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xd2/0x148 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
handle_overflow+0x1cf/0x21a lib/ubsan.c:190
__ubsan_handle_sub_overflow+0x2a/0x31 lib/ubsan.c:206
uinput_validate_absinfo.isra.2+0x194/0x1a0 drivers/input/misc/uinput.c:420
uinput_abs_setup drivers/input/misc/uinput.c:503 [inline]
uinput_ioctl_handler+0xa57/0x1bf0 drivers/input/misc/uinput.c:1036
uinput_ioctl+0x2d/0x40 drivers/input/misc/uinput.c:1048
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1aa/0x1160 fs/ioctl.c:690
ksys_ioctl+0x9e/0xb0 fs/ioctl.c:705
__do_sys_ioctl fs/ioctl.c:712 [inline]
__se_sys_ioctl fs/ioctl.c:710 [inline]
__x64_sys_ioctl+0x7e/0xc0 fs/ioctl.c:710
do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7b273c3c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f7b273c46cc RCX: 00000000004497b9
RDX: 0000000020000000 RSI: 0000004040105504 RDI: 0000000000000013
RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000005ca0 R14: 00000000006eed40 R15: 00007f7b273c4700
=========================================
Thanks,
Kyungtae Kim
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Dmitry Torokhov @ 2019-01-14 18:40 UTC (permalink / raw)
To: Kim Phillips, Benjamin Tissoires; +Cc: linux-kernel, Paul Menzel, linux-input
In-Reply-To: <22e2d619-0622-1816-2057-c9005288b46b@kimphillips.com>
On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> > Hi Kim,
>
> Hi Dmitry,
>
> > On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
> >> This patch is the result of seeing this message:
> >>
> >> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> >>
> >> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
> >> smbus_pnp_ids, the touchpad continues to work, and the above message
> >> goes away, but we now get:
> >>
> >> psmouse serio1: synaptics: Trying to set up SMBus access
> >> psmouse serio1: synaptics: SMbus companion is not ready yet
> >>
> >> With this patch applied, i.e., the PNP IDs are added to the forcepad
> >> array, the touchpad continues to work and all of the above messages
> >> disappear.
> >
> > Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> > physical button underneath it)? As far as I know there were only couple
> > of HP laptops with forcepads and when switching to RMI mode forcepads
> > need F21 handler that we do not currently have in the kernel.
>
> I see, no, I'm not sure, but assuming you're right, the IDs
> should be added to the smbus array instead, after fixing
> the SMbus "companion not ready" problem? Pointers for that and
> the below interrupts when touchpad idle after resume, welcome.
>
> Also, the link to get the RMI4 spec in
> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> is broken. Any pointers for that also appreciated.
OK, sorting it all out some more:
- because we do not have support for F21 necessary for forcepads adding
APIC ID to forcepad list actuallty disables SMbus companion mode, that
is why you no longer see "companion not ready" messages vs. setting
psmouse.synaptics_intertouch=1 module parameter.
- this does not really matter as your touchpad ends up being driven by
i2c-hid and hid-multitouch drivers, and that is how we wait it to
work, as we do not want to deviate from behavior on Windows since OEM
tested it (the device and firmware) in tha configuration.
- we need to figure out issue with interrupts on resume, maybe Benjamin
have seen it?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] input: touchscreen: fix link error
From: Dmitry Torokhov @ 2019-01-14 18:32 UTC (permalink / raw)
To: Anders Roxell; +Cc: linux-input, linux-kernel
In-Reply-To: <20190114095754.23175-1-anders.roxell@linaro.org>
On Mon, Jan 14, 2019 at 10:57:54AM +0100, Anders Roxell wrote:
> Fix link error when TOUCHSCREEN_RASPBERRYPI_FW is enabled as a module
> and the dependent module is built-in.
> The 'depends on RASPBERRYPI_FIRMWARE' by itself prevents the touchscreen
> driver from being built-in when the firmware is configured as a module.
> However, the '|| COMPILE_TEST' still allows it unless we explicitly
> prevent that configuration with '|| (RASPBERRYPI_FIRMWARE=n &&
> COMPILE_TEST)'
>
> ld: drivers/input/touchscreen/raspberrypi-ts.o: in function `rpi_ts_probe':
> raspberrypi-ts.c:(.text+0x3a8): undefined reference to `rpi_firmware_get'
> ld: raspberrypi-ts.c:(.text+0x3a8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_get'
> ld: raspberrypi-ts.c:(.text+0x4c8): undefined reference to `rpi_firmware_property'
> ld: raspberrypi-ts.c:(.text+0x4c8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_property'
>
> Rework so that TOUCHSCREEN_RASPBERRYPI_FW depends on
> RASPBERRYPI_FIRMWARE=n if COMPILE_TEST is enabled.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Applied, thank you.
> ---
> drivers/input/touchscreen/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index af6027cc7bbf..068dbbc610fc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -698,7 +698,7 @@ config TOUCHSCREEN_EDT_FT5X06
>
> config TOUCHSCREEN_RASPBERRYPI_FW
> tristate "Raspberry Pi's firmware base touch screen support"
> - depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> + depends on RASPBERRYPI_FIRMWARE || (RASPBERRYPI_FIRMWARE=n && COMPILE_TEST)
> help
> Say Y here if you have the official Raspberry Pi 7 inch screen on
> your system.
> --
> 2.19.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: mcs_touchkey - use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-14 17:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20190114063102.GA217283@dtor-ws>
On 1/14/19 12:31 AM, Dmitry Torokhov wrote:
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> Applied, thank you.
>
Thanks, Dmitry.
--
Gustavo
^ permalink raw reply
* Re: NULL pointer dereference when writing fuzzed data to /dev/uhid
From: Anatoly Trosinenko @ 2019-01-14 15:00 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Pavel Machek, Jiri Kosina, lkml, open list:HID CORE LAYER,
Roderick Colenbrander
In-Reply-To: <CAO-hwJKxRBdctUf59TJLW0G81gKXLiEoueheUxgtPO4x_=YieQ@mail.gmail.com>
Thank you for the explanation!
Best regards
Anatoly
пн, 14 янв. 2019 г. в 17:55, Benjamin Tissoires <benjamin.tissoires@redhat.com>:
>
> On Mon, Jan 14, 2019 at 3:23 PM Anatoly Trosinenko
> <anatoly.trosinenko@gmail.com> wrote:
> >
> > > fuzzed data is hard to discriminate from valid data.
> >
> > Just in case it can be helpful... If it is about manually "parsing"
> > descriptors to understand what is wrong by hands, then maybe Kaitai
> > Struct parser generator can help. I understand it is probably not
> > suited well for in-kernel binary parsing, but given a text-form
> > description of a format, it can visualize parsed binary data as a
> > hierarchical structure.
>
> Well, the data and parsing is pretty straightforward (see
> http://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html
> if you want to have an entertaining understanding, instead of reading
> the specs). The problem is the fuzzed data looks like a correct one,
> but there is garbage in the middle.
>
> And we can not simply rely on some global CRC that would prevent
> fuzzing because there is none. And the report descriptor is in the
> device, so we can't upgrade all of them.
>
> So in the end, sending a fuzz HID report descriptor is like sending a
> language grammar that doesn't mean anything. The parser says, "well,
> yes, why not", but sometime the rest of the drivers expect a little
> bit more, and this is where it gets hard to see.
>
> Cheers,
> Benjamin
>
> >
> > Best regards
> > Anatoly
> >
> > пн, 14 янв. 2019 г. в 02:09, Pavel Machek <pavel@ucw.cz>:
> >
> > >
> > > Hi!
> > >
> > > I just want to note that while these may not be high-priority, they
> > > are still security holes to be fixed.
> > >
> > > > > When writing the attached file to /dev/uhid, a NULL dereference occurs
> > > > > in kernel. As I understand, the problem is not UHID-specific, but is
> > > > > related to HID subsystem.
> > > >
> > > > Thanks for the report.
> > > > I wanted to tell you that I started investigating the other private
> > > > report you sent us, but couldn't find the time to properly come with a
> > > > fix as the fuzzed data is hard to discriminate from valid data.
> > > >
> > > > A couple of notes though:
> > > > - writing to uhid needs to be done by root. Any distribution that
> > > > doesn't enforce that is doomed to have several security issues
> > >
> > > We want to protect kernel from root, too.
> > >
> > > > - we could somehow reproduce those fuzzed data on a USB or Bluetooth
> > > > connection, but that would require physical access to the device, so
> > > > you are doomed also
> > >
> > > Not neccessarily. Imagine a kiosk where PC is protected but keyboard
> > > uses USB connection. If our USB stack is buggy, you are doomed... but
> > > you should not be ;-).
> > > Pavel
> > > --
> > > (english) http://www.livejournal.com/~pavelmachek
> > > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: NULL pointer dereference when writing fuzzed data to /dev/uhid
From: Benjamin Tissoires @ 2019-01-14 14:55 UTC (permalink / raw)
To: Anatoly Trosinenko
Cc: Pavel Machek, Jiri Kosina, lkml, open list:HID CORE LAYER,
Roderick Colenbrander
In-Reply-To: <CAE5jQCd+HBh3hCkQW4SR4QOHAGRS3wEuZfT4q1N6V8g9rrpBuA@mail.gmail.com>
On Mon, Jan 14, 2019 at 3:23 PM Anatoly Trosinenko
<anatoly.trosinenko@gmail.com> wrote:
>
> > fuzzed data is hard to discriminate from valid data.
>
> Just in case it can be helpful... If it is about manually "parsing"
> descriptors to understand what is wrong by hands, then maybe Kaitai
> Struct parser generator can help. I understand it is probably not
> suited well for in-kernel binary parsing, but given a text-form
> description of a format, it can visualize parsed binary data as a
> hierarchical structure.
Well, the data and parsing is pretty straightforward (see
http://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html
if you want to have an entertaining understanding, instead of reading
the specs). The problem is the fuzzed data looks like a correct one,
but there is garbage in the middle.
And we can not simply rely on some global CRC that would prevent
fuzzing because there is none. And the report descriptor is in the
device, so we can't upgrade all of them.
So in the end, sending a fuzz HID report descriptor is like sending a
language grammar that doesn't mean anything. The parser says, "well,
yes, why not", but sometime the rest of the drivers expect a little
bit more, and this is where it gets hard to see.
Cheers,
Benjamin
>
> Best regards
> Anatoly
>
> пн, 14 янв. 2019 г. в 02:09, Pavel Machek <pavel@ucw.cz>:
>
> >
> > Hi!
> >
> > I just want to note that while these may not be high-priority, they
> > are still security holes to be fixed.
> >
> > > > When writing the attached file to /dev/uhid, a NULL dereference occurs
> > > > in kernel. As I understand, the problem is not UHID-specific, but is
> > > > related to HID subsystem.
> > >
> > > Thanks for the report.
> > > I wanted to tell you that I started investigating the other private
> > > report you sent us, but couldn't find the time to properly come with a
> > > fix as the fuzzed data is hard to discriminate from valid data.
> > >
> > > A couple of notes though:
> > > - writing to uhid needs to be done by root. Any distribution that
> > > doesn't enforce that is doomed to have several security issues
> >
> > We want to protect kernel from root, too.
> >
> > > - we could somehow reproduce those fuzzed data on a USB or Bluetooth
> > > connection, but that would require physical access to the device, so
> > > you are doomed also
> >
> > Not neccessarily. Imagine a kiosk where PC is protected but keyboard
> > uses USB connection. If our USB stack is buggy, you are doomed... but
> > you should not be ;-).
> > Pavel
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: NULL pointer dereference when writing fuzzed data to /dev/uhid
From: Anatoly Trosinenko @ 2019-01-14 14:23 UTC (permalink / raw)
To: Pavel Machek
Cc: Benjamin Tissoires, Jiri Kosina, lkml, open list:HID CORE LAYER,
Roderick Colenbrander
In-Reply-To: <20190113230946.GA18710@amd>
> fuzzed data is hard to discriminate from valid data.
Just in case it can be helpful... If it is about manually "parsing"
descriptors to understand what is wrong by hands, then maybe Kaitai
Struct parser generator can help. I understand it is probably not
suited well for in-kernel binary parsing, but given a text-form
description of a format, it can visualize parsed binary data as a
hierarchical structure.
Best regards
Anatoly
пн, 14 янв. 2019 г. в 02:09, Pavel Machek <pavel@ucw.cz>:
>
> Hi!
>
> I just want to note that while these may not be high-priority, they
> are still security holes to be fixed.
>
> > > When writing the attached file to /dev/uhid, a NULL dereference occurs
> > > in kernel. As I understand, the problem is not UHID-specific, but is
> > > related to HID subsystem.
> >
> > Thanks for the report.
> > I wanted to tell you that I started investigating the other private
> > report you sent us, but couldn't find the time to properly come with a
> > fix as the fuzzed data is hard to discriminate from valid data.
> >
> > A couple of notes though:
> > - writing to uhid needs to be done by root. Any distribution that
> > doesn't enforce that is doomed to have several security issues
>
> We want to protect kernel from root, too.
>
> > - we could somehow reproduce those fuzzed data on a USB or Bluetooth
> > connection, but that would require physical access to the device, so
> > you are doomed also
>
> Not neccessarily. Imagine a kiosk where PC is protected but keyboard
> uses USB connection. If our USB stack is buggy, you are doomed... but
> you should not be ;-).
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Jiri Kosina @ 2019-01-14 11:18 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20190114084734.3362-1-kai.heng.feng@canonical.com>
On Mon, 14 Jan 2019, Kai-Heng Feng wrote:
> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
> but there's no input event from HID subsystem.
>
> Turns out it reports some invalid data:
> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00
>
> After some trial and error, it's another device that doesn't work well
> with ON/SLEEP commands. Disable runtime PM to fix the issue.
Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am
wondering though we are we seeing these at all - do other OSes not do the
runtime PM on i2c at all?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH RESEND v8 6/6] watchdog: stpmic1: add stpmic1 watchdog driver
From: Pascal PAILLET-LME @ 2019-01-14 10:05 UTC (permalink / raw)
To: 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,
axel.lin@ingics.com
Cc: Pascal PAILLET-LME
In-Reply-To: <1547460290-21049-1-git-send-email-p.paillet@st.com>
The stpmic1 PMIC embeds a watchdog which is disabled by default. As soon
as the watchdog is started, it must be refreshed periodically otherwise
the PMIC goes off.
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
changes in v8: nothing
drivers/watchdog/Kconfig | 12 ++++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stpmic1_wdt.c | 139 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 152 insertions(+)
create mode 100644 drivers/watchdog/stpmic1_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2d64333..cc5155b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -817,6 +817,18 @@ config STM32_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called stm32_iwdg.
+config STPMIC1_WATCHDOG
+ tristate "STPMIC1 PMIC watchdog support"
+ depends on MFD_STPMIC1
+ select WATCHDOG_CORE
+ help
+ Say Y here to include watchdog support embedded into STPMIC1 PMIC.
+ If the watchdog timer expires, stpmic1 will shut down all its power
+ supplies.
+
+ To compile this driver as a module, choose M here: the
+ module will be called spmic1_wdt.
+
config UNIPHIER_WATCHDOG
tristate "UniPhier watchdog support"
depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f69cdff..bdc072c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -218,3 +218,4 @@ obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
obj-$(CONFIG_MENZ069_WATCHDOG) += menz69_wdt.o
obj-$(CONFIG_RAVE_SP_WATCHDOG) += rave-sp-wdt.o
+obj-$(CONFIG_STPMIC1_WATCHDOG) += stpmic1_wdt.o
diff --git a/drivers/watchdog/stpmic1_wdt.c b/drivers/watchdog/stpmic1_wdt.c
new file mode 100644
index 0000000..ad431d8
--- /dev/null
+++ b/drivers/watchdog/stpmic1_wdt.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet <p.paillet@st.com> for STMicroelectronics.
+
+#include <linux/kernel.h>
+#include <linux/mfd/stpmic1.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/watchdog.h>
+
+/* WATCHDOG CONTROL REGISTER bit */
+#define WDT_START BIT(0)
+#define WDT_PING BIT(1)
+#define WDT_START_MASK BIT(0)
+#define WDT_PING_MASK BIT(1)
+#define WDT_STOP 0
+
+#define PMIC_WDT_MIN_TIMEOUT 1
+#define PMIC_WDT_MAX_TIMEOUT 256
+#define PMIC_WDT_DEFAULT_TIMEOUT 30
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct stpmic1_wdt {
+ struct stpmic1 *pmic;
+ struct watchdog_device wdtdev;
+};
+
+static int pmic_wdt_start(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_START_MASK, WDT_START);
+}
+
+static int pmic_wdt_stop(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_START_MASK, WDT_STOP);
+}
+
+static int pmic_wdt_ping(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_PING_MASK, WDT_PING);
+}
+
+static int pmic_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ wdd->timeout = timeout;
+ /* timeout is equal to register value + 1 */
+ return regmap_write(wdt->pmic->regmap, WCHDG_TIMER_CR, timeout - 1);
+}
+
+static const struct watchdog_info pmic_watchdog_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .identity = "STPMIC1 PMIC Watchdog",
+};
+
+static const struct watchdog_ops pmic_watchdog_ops = {
+ .owner = THIS_MODULE,
+ .start = pmic_wdt_start,
+ .stop = pmic_wdt_stop,
+ .ping = pmic_wdt_ping,
+ .set_timeout = pmic_wdt_set_timeout,
+};
+
+static int pmic_wdt_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct stpmic1 *pmic;
+ struct stpmic1_wdt *wdt;
+
+ if (!pdev->dev.parent)
+ return -EINVAL;
+
+ pmic = dev_get_drvdata(pdev->dev.parent);
+ if (!pmic)
+ return -EINVAL;
+
+ wdt = devm_kzalloc(&pdev->dev, sizeof(struct stpmic1_wdt), GFP_KERNEL);
+ if (!wdt)
+ return -ENOMEM;
+
+ wdt->pmic = pmic;
+
+ wdt->wdtdev.info = &pmic_watchdog_info;
+ wdt->wdtdev.ops = &pmic_watchdog_ops;
+ wdt->wdtdev.min_timeout = PMIC_WDT_MIN_TIMEOUT;
+ wdt->wdtdev.max_timeout = PMIC_WDT_MAX_TIMEOUT;
+ wdt->wdtdev.parent = &pdev->dev;
+
+ wdt->wdtdev.timeout = PMIC_WDT_DEFAULT_TIMEOUT;
+ watchdog_init_timeout(&wdt->wdtdev, 0, &pdev->dev);
+
+ watchdog_set_nowayout(&wdt->wdtdev, nowayout);
+ watchdog_set_drvdata(&wdt->wdtdev, wdt);
+
+ ret = devm_watchdog_register_device(&pdev->dev, &wdt->wdtdev);
+ if (ret)
+ return ret;
+
+ dev_dbg(wdt->pmic->dev, "PMIC Watchdog driver probed\n");
+ return 0;
+}
+
+static const struct of_device_id of_pmic_wdt_match[] = {
+ { .compatible = "st,stpmic1-wdt" },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, of_pmic_wdt_match);
+
+static struct platform_driver stpmic1_wdt_driver = {
+ .probe = pmic_wdt_probe,
+ .driver = {
+ .name = "stpmic1-wdt",
+ .of_match_table = of_pmic_wdt_match,
+ },
+};
+module_platform_driver(stpmic1_wdt_driver);
+
+MODULE_DESCRIPTION("Watchdog driver for STPMIC1 device");
+MODULE_AUTHOR("Pascal Paillet <p.paillet@st.com>");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH RESEND v8 4/6] input: stpmic1: add stpmic1 onkey driver
From: Pascal PAILLET-LME @ 2019-01-14 10:05 UTC (permalink / raw)
To: 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,
axel.lin@ingics.com
Cc: Pascal PAILLET-LME
In-Reply-To: <1547460290-21049-1-git-send-email-p.paillet@st.com>
The stpmic1 pmic is able to manage an onkey button. This driver exposes
the stpmic1 onkey as an input device. It can also 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>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
changes in v8: nothing
drivers/input/misc/Kconfig | 11 +++
drivers/input/misc/Makefile | 2 +
drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++++++++++++++++++++
3 files changed, 211 insertions(+)
create mode 100644 drivers/input/misc/stpmic1_onkey.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..279fb02 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,15 @@ config INPUT_SC27XX_VIBRA
To compile this driver as a module, choose M here. The module will
be called sc27xx_vibra.
+config INPUT_STPMIC1_ONKEY
+ tristate "STPMIC1 PMIC Onkey support"
+ depends on MFD_STPMIC1
+ help
+ Say Y to enable support of onkey embedded into STPMIC1 PMIC. onkey
+ can be used to wakeup from low power modes and force a shut-down on
+ long press.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stpmic1_onkey.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..1b44202 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
+obj-$(CONFIG_INPUT_STPMIC1_ONKEY) += stpmic1_onkey.o
obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON) += tps65218-pwrbutton.o
obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON) += twl4030-pwrbutton.o
obj-$(CONFIG_INPUT_TWL4030_VIBRA) += twl4030-vibra.o
@@ -81,3 +82,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK) += yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+
diff --git a/drivers/input/misc/stpmic1_onkey.c b/drivers/input/misc/stpmic1_onkey.c
new file mode 100644
index 0000000..7b49c99
--- /dev/null
+++ b/drivers/input/misc/stpmic1_onkey.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet <p.paillet@st.com> for STMicroelectronics.
+
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/stpmic1.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+/**
+ * struct stpmic1_onkey - OnKey data
+ * @input_dev: pointer to input device
+ * @irq_falling: irq that we are hooked on to
+ * @irq_rising: irq that we are hooked on to
+ */
+struct stpmic1_onkey {
+ struct input_dev *input_dev;
+ int irq_falling;
+ int irq_rising;
+};
+
+static irqreturn_t onkey_falling_irq(int irq, void *ponkey)
+{
+ struct stpmic1_onkey *onkey = ponkey;
+ struct input_dev *input_dev = onkey->input_dev;
+
+ input_report_key(input_dev, KEY_POWER, 1);
+ pm_wakeup_event(input_dev->dev.parent, 0);
+ input_sync(input_dev);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t onkey_rising_irq(int irq, void *ponkey)
+{
+ struct stpmic1_onkey *onkey = ponkey;
+ struct input_dev *input_dev = onkey->input_dev;
+
+ input_report_key(input_dev, KEY_POWER, 0);
+ pm_wakeup_event(input_dev->dev.parent, 0);
+ input_sync(input_dev);
+
+ return IRQ_HANDLED;
+}
+
+static int stpmic1_onkey_probe(struct platform_device *pdev)
+{
+ struct stpmic1 *pmic = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = &pdev->dev;
+ struct input_dev *input_dev;
+ struct stpmic1_onkey *onkey;
+ unsigned int val, reg = 0;
+ int error;
+
+ onkey = devm_kzalloc(dev, sizeof(*onkey), GFP_KERNEL);
+ if (!onkey)
+ return -ENOMEM;
+
+ onkey->irq_falling = platform_get_irq_byname(pdev, "onkey-falling");
+ if (onkey->irq_falling < 0) {
+ dev_err(dev, "failed: request IRQ onkey-falling %d\n",
+ onkey->irq_falling);
+ return onkey->irq_falling;
+ }
+
+ onkey->irq_rising = platform_get_irq_byname(pdev, "onkey-rising");
+ if (onkey->irq_rising < 0) {
+ dev_err(dev, "failed: request IRQ onkey-rising %d\n",
+ onkey->irq_rising);
+ return onkey->irq_rising;
+ }
+
+ if (!device_property_read_u32(dev, "power-off-time-sec", &val)) {
+ if (val > 0 && val <= 16) {
+ dev_dbg(dev, "power-off-time=%d seconds\n", val);
+ reg |= PONKEY_PWR_OFF;
+ reg |= ((16 - val) & PONKEY_TURNOFF_TIMER_MASK);
+ } else {
+ dev_err(dev, "power-off-time-sec out of range\n");
+ return -EINVAL;
+ }
+ }
+
+ if (device_property_present(dev, "st,onkey-clear-cc-flag"))
+ reg |= PONKEY_CC_FLAG_CLEAR;
+
+ error = regmap_update_bits(pmic->regmap, PKEY_TURNOFF_CR,
+ PONKEY_TURNOFF_MASK, reg);
+ if (error) {
+ dev_err(dev, "PKEY_TURNOFF_CR write failed: %d\n", error);
+ return error;
+ }
+
+ if (device_property_present(dev, "st,onkey-pu-inactive")) {
+ error = regmap_update_bits(pmic->regmap, PADS_PULL_CR,
+ PONKEY_PU_INACTIVE,
+ PONKEY_PU_INACTIVE);
+ if (error) {
+ dev_err(dev, "ONKEY Pads configuration failed: %d\n",
+ error);
+ return error;
+ }
+ }
+
+ input_dev = devm_input_allocate_device(dev);
+ if (!input_dev) {
+ dev_err(dev, "Can't allocate Pwr Onkey Input Device\n");
+ return -ENOMEM;
+ }
+
+ input_dev->name = "pmic_onkey";
+ input_dev->phys = "pmic_onkey/input0";
+
+ input_set_capability(input_dev, EV_KEY, KEY_POWER);
+
+ onkey->input_dev = input_dev;
+
+ /* interrupt is nested in a thread */
+ error = devm_request_threaded_irq(dev, onkey->irq_falling, NULL,
+ onkey_falling_irq, IRQF_ONESHOT,
+ dev_name(dev), onkey);
+ if (error) {
+ dev_err(dev, "Can't get IRQ Onkey Falling: %d\n", error);
+ return error;
+ }
+
+ error = devm_request_threaded_irq(dev, onkey->irq_rising, NULL,
+ onkey_rising_irq, IRQF_ONESHOT,
+ dev_name(dev), onkey);
+ if (error) {
+ dev_err(dev, "Can't get IRQ Onkey Rising: %d\n", error);
+ return error;
+ }
+
+ error = input_register_device(input_dev);
+ if (error) {
+ dev_err(dev, "Can't register power button: %d\n", error);
+ return error;
+ }
+
+ platform_set_drvdata(pdev, onkey);
+ device_init_wakeup(dev, true);
+
+ return 0;
+}
+
+static int __maybe_unused stpmic1_onkey_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct stpmic1_onkey *onkey = platform_get_drvdata(pdev);
+
+ if (device_may_wakeup(dev)) {
+ enable_irq_wake(onkey->irq_falling);
+ enable_irq_wake(onkey->irq_rising);
+ }
+ return 0;
+}
+
+static int __maybe_unused stpmic1_onkey_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct stpmic1_onkey *onkey = platform_get_drvdata(pdev);
+
+ if (device_may_wakeup(dev)) {
+ disable_irq_wake(onkey->irq_falling);
+ disable_irq_wake(onkey->irq_rising);
+ }
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(stpmic1_onkey_pm,
+ stpmic1_onkey_suspend,
+ stpmic1_onkey_resume);
+
+static const struct of_device_id of_stpmic1_onkey_match[] = {
+ { .compatible = "st,stpmic1-onkey" },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, of_stpmic1_onkey_match);
+
+static struct platform_driver stpmic1_onkey_driver = {
+ .probe = stpmic1_onkey_probe,
+ .driver = {
+ .name = "stpmic1_onkey",
+ .of_match_table = of_match_ptr(of_stpmic1_onkey_match),
+ .pm = &stpmic1_onkey_pm,
+ },
+};
+module_platform_driver(stpmic1_onkey_driver);
+
+MODULE_DESCRIPTION("Onkey driver for STPMIC1");
+MODULE_AUTHOR("Pascal Paillet <p.paillet@st.com>");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH RESEND v8 5/6] dt-bindings: watchdog: document stpmic1 pmic watchdog
From: Pascal PAILLET-LME @ 2019-01-14 10:05 UTC (permalink / raw)
To: 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,
axel.lin@ingics.com
Cc: Pascal PAILLET-LME
In-Reply-To: <1547460290-21049-1-git-send-email-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>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
changes in v8: nothing
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
diff --git a/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
new file mode 100644
index 0000000..7cc1407
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
@@ -0,0 +1,11 @@
+STMicroelectronics STPMIC1 Watchdog
+
+Required properties:
+
+- compatible : should be "st,stpmic1-wdt"
+
+Example:
+
+watchdog {
+ compatible = "st,stpmic1-wdt";
+};
--
1.9.1
^ permalink raw reply related
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