Re: [PATCH 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence

3 = pci_pr3_present(pdev); if (*has_pr3 && !pdev->bridge_d3) { /* * ... */ pci_d3cold_disable(pdev); *has_pr3 = false; } For the 1/2 patch, Reviewed-by: Peter Wu -- Kind regards, Peter Wu https://lekensteyn.nl

[PATCH] docs: ftrace: clarify when tracing is disabled by the trace file

The current text could mislead the user into believing that only read() disables tracing. Clarify that any open() call that requests read access disables tracing. Link: https://lkml.kernel.org/r/CAADnVQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqXOS2WpMj=q=l...@mail.gmail.com Signed-off-by: Peter Wu

[PATCH] bpf.2: update enum bpf_map_type and enum bpf_prog_type

Taken from Linux v5.3-rc2. Add a reference to the header file to save the future reader some time figuring out whether more entries exist. Signed-off-by: Peter Wu --- man2/bpf.2 | 27 +++ 1 file changed, 27 insertions(+) diff --git a/man2/bpf.2 b/man2/bpf.2 index

Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup

On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote: > > > Den 24.12.2018 00.10, skrev Peter Wu: > > On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote: > > > > > > > > > Den 23.12.2018 01.55, skrev Peter Wu: >

Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup

On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote: > > > Den 23.12.2018 01.55, skrev Peter Wu: > > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, > > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini

Re: [LKP] [bochs] df2052cc92: WARNING:at_drivers/gpu/drm/drm_mode_config.c:#drm_mode_config_cleanup

_helper->fb); // yay! } Due to calling "drm_fb_helper_fini" however, "dev->fb_helper" will be NULL and thus this function does nothing on the error path. So in summary, "drm_fb_helper_fbdev_setup" calls the driver callback drm_fb_helper_funcs::fb_p

[PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup

0x18/0x40 This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian Link: https://lkml.kernel.org/r/20181223004315.GA11455@al Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") Reported-by: kernel te

Re: [PATCH 4.8 14/37] drm/amdgpu: fix power state when port pm is unavailable

On Wed, Nov 30, 2016 at 12:53:19PM +0100, Greg Kroah-Hartman wrote: > On Wed, Nov 30, 2016 at 11:51:00AM +0100, Peter Wu wrote: [..] > > Please delay this patch (amd tje mext radeon patch, 15/37), it contains > > a regression for which these patches (from drm-fixes) are needed: &

Re: [PATCH 4.8 14/37] drm/amdgpu: fix power state when port pm is unavailable

On Wed, Nov 30, 2016 at 12:53:19PM +0100, Greg Kroah-Hartman wrote: > On Wed, Nov 30, 2016 at 11:51:00AM +0100, Peter Wu wrote: [..] > > Please delay this patch (amd tje mext radeon patch, 15/37), it contains > > a regression for which these patches (from drm-fixes) are needed: &

Re: [PATCH 4.8 14/37] drm/amdgpu: fix power state when port pm is unavailable

ded: drm/radeon: fix check for port PM availability drm/amdgpu: fix check for port PM availability Patches should appear in v4.9-rc8 via https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes Kind regards, Peter > -- > > From: Peter Wu <pe...@lekensteyn.

Re: [PATCH 4.8 14/37] drm/amdgpu: fix power state when port pm is unavailable

ded: drm/radeon: fix check for port PM availability drm/amdgpu: fix check for port PM availability Patches should appear in v4.9-rc8 via https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes Kind regards, Peter > -- > > From: Peter Wu

Re: [PATCH reworded] x86/kbuild: enable modversions for symbols exported from asm

: Adam Borowski <kilob...@angband.pl> > Tested-by: Kalle Valo <kv...@codeaurora.org> > Acked-by: Nicholas Piggin <npig...@gmail.com> > Tested-by: Peter Wu <oe...@lekensteyn.nl> Typo: oeter@.. -> peter@.. > --- > arch/x86/include/asm/asm-prototypes.h | 12 +

Re: [PATCH reworded] x86/kbuild: enable modversions for symbols exported from asm

dam Borowski > Tested-by: Kalle Valo > Acked-by: Nicholas Piggin > Tested-by: Peter Wu Typo: oeter@.. -> peter@.. > --- > arch/x86/include/asm/asm-prototypes.h | 12 > include/asm-generic/asm-prototypes.h | 7 +++ > 2 files changed, 19 insertions(+) >

Re: [PATCH resend] kbuild: provide include/asm/asm-prototypes.h for x86

ou want to use that as-is or rewrite it, no problem). > > You can add Acked-by: Nicholas Piggin <npig...@gmail.com> Hi Adam, Nicholas, Thanks for the patch! I have confirmed that this fixes the defconfig and the normal .config build I use for debugging, so: Tested-by: Peter Wu

Re: [PATCH resend] kbuild: provide include/asm/asm-prototypes.h for x86

ou want to use that as-is or rewrite it, no problem). > > You can add Acked-by: Nicholas Piggin Hi Adam, Nicholas, Thanks for the patch! I have confirmed that this fixes the defconfig and the normal .config build I use for debugging, so: Tested-by: Peter Wu It might also be worth to me

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

0x __put_user_1vmlinux EXPORT_SYMBOL 0x __get_user_1vmlinux EXPORT_SYMBOL 0x copy_user_generic_unrolled vmlinux EXPORT_SYMBOL Kind regards, Peter On Tue, Nov 08, 2016 at 12:33:34PM +1100, Nicholas Piggin wrote: > On Mon, 7 Nov 2016 22:39:07 +0100 > Pet

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

0x __put_user_1vmlinux EXPORT_SYMBOL 0x __get_user_1vmlinux EXPORT_SYMBOL 0x copy_user_generic_unrolled vmlinux EXPORT_SYMBOL Kind regards, Peter On Tue, Nov 08, 2016 at 12:33:34PM +1100, Nicholas Piggin wrote: > On Mon, 7 Nov 2016 22:39:07 +0100 > Pe

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

On Mon, Nov 07, 2016 at 02:10:12PM -0500, Vince Weaver wrote: > On Thu, 27 Oct 2016, Peter Wu wrote: > > > I can confirm Olivers issue, the current mainline kernel fails to boot > > on kernels with CONFIG_MODVERSIONS=y. Bisection points to: &

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

On Mon, Nov 07, 2016 at 02:10:12PM -0500, Vince Weaver wrote: > On Thu, 27 Oct 2016, Peter Wu wrote: > > > I can confirm Olivers issue, the current mainline kernel fails to boot > > on kernels with CONFIG_MODVERSIONS=y. Bisection points to: &

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

Hey Al, Michal, I can confirm Olivers issue, the current mainline kernel fails to boot on kernels with CONFIG_MODVERSIONS=y. Bisection points to: commit 784d5699eddc55878627da20d3fe0c8542e2f1a2 Author: Al Viro Date: Mon Jan 11 11:04:34 2016 -0500

Re: 'kbuild' merge before 4.9-rc1 breaks build and boot

Hey Al, Michal, I can confirm Olivers issue, the current mainline kernel fails to boot on kernels with CONFIG_MODVERSIONS=y. Bisection points to: commit 784d5699eddc55878627da20d3fe0c8542e2f1a2 Author: Al Viro Date: Mon Jan 11 11:04:34 2016 -0500 x86: move exports to

Re: Kernel Freeze with American Megatrends BIOS

On Wed, Aug 31, 2016 at 02:21:31PM +0200, Roland Singer wrote: > Am 31.08.2016 um 13:46 schrieb Peter Wu: > > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: > >> Am 30.08.2016 um 21:53 schrieb Peter Wu: > >>> On Mon, Aug 29, 2016 at 11:02:1

Re: Kernel Freeze with American Megatrends BIOS

On Wed, Aug 31, 2016 at 02:21:31PM +0200, Roland Singer wrote: > Am 31.08.2016 um 13:46 schrieb Peter Wu: > > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: > >> Am 30.08.2016 um 21:53 schrieb Peter Wu: > >>> On Mon, Aug 29, 2016 at 11:02:1

Re: Kernel Freeze with American Megatrends BIOS

On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: > Am 30.08.2016 um 21:53 schrieb Peter Wu: > > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: > >> [+cc linux-acpi, linux-kernel, dri-devel] > >> > >> Hi Roland, > >>

Re: Kernel Freeze with American Megatrends BIOS

On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote: > Am 30.08.2016 um 21:53 schrieb Peter Wu: > > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: > >> [+cc linux-acpi, linux-kernel, dri-devel] > >> > >> Hi Roland, > >>

Re: Kernel Freeze with American Megatrends BIOS

On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: > [+cc linux-acpi, linux-kernel, dri-devel] > > Hi Roland, > > I have no idea how to debug this problem. Are you seeing something > that suggests it may be a PCI problem? Yes I suspect there is an ACPI and/ or PCI problem, possibly

Re: Kernel Freeze with American Megatrends BIOS

On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote: > [+cc linux-acpi, linux-kernel, dri-devel] > > Hi Roland, > > I have no idea how to debug this problem. Are you seeing something > that suggests it may be a PCI problem? Yes I suspect there is an ACPI and/ or PCI problem, possibly

Re: Kernel Freeze with American Megatrends BIOS

intent is to check the power state, not use the suspend functionality of bbswitch, if you load bbswitch without module options amd do not write to /proc/bbswitch, then it allows you to read out the actual status (you could also just use lspci -H1 for that though). -- Kind regards, Peter Wu https://lekensteyn.nl

Re: Kernel Freeze with American Megatrends BIOS

te, not use the suspend functionality of bbswitch, if you load bbswitch without module options amd do not write to /proc/bbswitch, then it allows you to read out the actual status (you could also just use lspci -H1 for that though). -- Kind regards, Peter Wu https://lekensteyn.nl

[PATCH] block: add start and size to ABI documentation

Document the start and size fields (which were introduced in commit v2.5.42-215-gb288f6a) to avoid guesswork on the unit. Signed-off-by: Peter Wu --- Hi, As the meaning has not changed for over 13 years, I would like to formalize these attributes such that users can rely on it[1][2]. The sector

[PATCH] block: add start and size to ABI documentation

Document the start and size fields (which were introduced in commit v2.5.42-215-gb288f6a) to avoid guesswork on the unit. Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- Hi, As the meaning has not changed for over 13 years, I would like to formalize these attributes such that users ca

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

On Tue, Dec 08, 2015 at 12:39:12PM +, Hayes Wang wrote: > Peter Wu [mailto:pe...@lekensteyn.nl] > > Sent: Tuesday, December 08, 2015 7:18 PM > > > > When an interface is brought up which was previously suspended (via > > runtime PM), it would hang. This happens bec

[PATCH v2] r8152: fix lockup when runtime PM is enabled

is up, rtl8152_open is not called. - When link is down during system/auto suspend/resume, it is not set. Fixes: 41cec84cf285 ("r8152: don't enable napi before rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu --- v2: moved rtl_runtime_suspend_e

Re: [PATCH] r8152: fix lockup when runtime PM is enabled

On Tue, Dec 08, 2015 at 03:18:59AM +, Hayes Wang wrote: > Peter Wu > > Sent: Tuesday, December 08, 2015 12:59 AM > [...] > > + if (tp->netdev->flags & IFF_UP) { > > Maybe you could just replace the checking of netif_running(tp->n

[PATCH v2] r8152: fix lockup when runtime PM is enabled

is up, rtl8152_open is not called. - When link is down during system/auto suspend/resume, it is not set. Fixes: 41cec84cf285 ("r8152: don't enable napi before rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu <pe...@lekensteyn.nl>

Re: [PATCH] r8152: fix lockup when runtime PM is enabled

On Tue, Dec 08, 2015 at 03:18:59AM +, Hayes Wang wrote: > Peter Wu > > Sent: Tuesday, December 08, 2015 12:59 AM > [...] > > + if (tp->netdev->flags & IFF_UP) { > > Maybe you could just replace the checking of netif_running(tp->n

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

On Tue, Dec 08, 2015 at 12:39:12PM +, Hayes Wang wrote: > Peter Wu [mailto:pe...@lekensteyn.nl] > > Sent: Tuesday, December 08, 2015 7:18 PM > > > > When an interface is brought up which was previously suspended (via > > runtime PM), it would hang. This happens bec

[PATCH] r8152: fix lockup when runtime PM is enabled

efore rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu --- drivers/net/usb/r8152.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index d9427ca..b8b0

Re: (4.3.0) r8152: deadlock related to runtime suspend?

On Mon, Dec 07, 2015 at 07:08:50PM +0800, Lu Baolu wrote: > > > On 12/07/2015 05:37 PM, Peter Wu wrote: > > On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote: > >> Hi Peter, > >> > >> Have you ever tried disabling auto-pm? Did things go smoothly

Re: (4.3.0) r8152: deadlock related to runtime suspend?

ning (when trying to bring an interface down if I remember correctly). Its trace can be found on the bottom of this mail. I'll keep testing. For the lockdep warning, my initial guess is that calling schedule_delayed_work_sync under tp->lock is a bad idea because scheduled work can execute an

[PATCH] r8152: fix lockup when runtime PM is enabled

efore rx ready") Link: https://lkml.kernel.org/r/20151205105912.GA1766@al Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- drivers/net/usb/r8152.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152

Re: (4.3.0) r8152: deadlock related to runtime suspend?

ning (when trying to bring an interface down if I remember correctly). Its trace can be found on the bottom of this mail. I'll keep testing. For the lockdep warning, my initial guess is that calling schedule_delayed_work_sync under tp->lock is a bad idea because scheduled work can execute an

Re: (4.3.0) r8152: deadlock related to runtime suspend?

On Mon, Dec 07, 2015 at 07:08:50PM +0800, Lu Baolu wrote: > > > On 12/07/2015 05:37 PM, Peter Wu wrote: > > On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote: > >> Hi Peter, > >> > >> Have you ever tried disabling auto-pm? Did things go smoothly

[PATCH v2] rtlwifi: fix memory leak for USB device

-off-by: Peter Wu --- v2: updated commit message based on Larry's feedback v1: https://lkml.kernel.org/r/1449424677-3140-1-git-send-email-pe...@lekensteyn.nl Tested with v4.3, rebased on v4.4-rc3 (changed paths). The bug goes back to its introduction in the v2.6.x kernel. --- drivers/net/wireless

Re: [PATCH] rtlwifi: fix gigantic memleak in rtl_usb

On Sun, Dec 06, 2015 at 02:18:36PM -0600, Larry Finger wrote: > On 12/06/2015 11:57 AM, Peter Wu wrote: > >Free skb for received frames with a wrong checksum. > > > >While using the rtl8192cu driver in monitor mode, somehow 5G of memory > >was permanently lost (observab

[PATCH] rtlwifi: fix gigantic memleak in rtl_usb

iw wlan1 set channel 11 Then stream a video on a smartphone on channel 11. Without this patch the memory usage grows linearly with the number of received packets: grep MemAvailable /proc/meminfo ip -s link show dev wlan1 Signed-off-by: Peter Wu --- Hi, This issue has existed since

[PATCH] rtlwifi: fix gigantic memleak in rtl_usb

iw wlan1 set channel 11 Then stream a video on a smartphone on channel 11. Without this patch the memory usage grows linearly with the number of received packets: grep MemAvailable /proc/meminfo ip -s link show dev wlan1 Signed-off-by: Peter Wu <pe...@lekensteyn.nl> --- Hi, This

[PATCH v2] rtlwifi: fix memory leak for USB device

-off-by: Peter Wu <pe...@lekensteyn.nl> --- v2: updated commit message based on Larry's feedback v1: https://lkml.kernel.org/r/1449424677-3140-1-git-send-email-pe...@lekensteyn.nl Tested with v4.3, rebased on v4.4-rc3 (changed paths). The bug goes back to its introduction in the v2.6.x

Re: [PATCH] rtlwifi: fix gigantic memleak in rtl_usb

On Sun, Dec 06, 2015 at 02:18:36PM -0600, Larry Finger wrote: > On 12/06/2015 11:57 AM, Peter Wu wrote: > >Free skb for received frames with a wrong checksum. > > > >While using the rtl8192cu driver in monitor mode, somehow 5G of memory > >was permanently lost (observab

(4.3.0) r8152: deadlock related to runtime suspend?

or all devices). This is the USB 3.0 port: 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) -- Kind regards, Peter Wu https://lekensteyn.nl Dec 05 00:32:58 al kernel: usb 3-1: USB disconnect, device number 4 Dec 05 00:34:43 al NetworkManag

(4.3.0) r8152: deadlock related to runtime suspend?

or all devices). This is the USB 3.0 port: 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) -- Kind regards, Peter Wu https://lekensteyn.nl Dec 05 00:32:58 al kernel: usb 3-1: USB disconnect, device number 4 Dec 05 00:34:43 al NetworkManag

[PATCH] Documentation: Remove output class document

The output class implementation removed a year ago (in commit f167a64e, "video / output: Drop display output class support"). Drop this obsolete documentation file. Signed-off-by: Peter Wu --- Documentation/video-output.txt | 34 -- 1 file changed, 34

[PATCH] Documentation: Remove output class document

The output class implementation removed a year ago (in commit f167a64e, video / output: Drop display output class support). Drop this obsolete documentation file. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- Documentation/video-output.txt | 34 -- 1 file

Re: [PATCH v2] HID: logitech-hidpp: store the name of the device in struct hidpp

e input node is not created. > > The input node will be created only if we have a connection which > lasts long enough to retrieve all the requested information: > name, protocol, and specific configuration. > > Reviewed-by: Peter Wu > Tested-by: Peter Wu > Signed-of

Re: [PATCH v2] HID: logitech-hidpp: store the name of the device in struct hidpp

node will be created only if we have a connection which lasts long enough to retrieve all the requested information: name, protocol, and specific configuration. Reviewed-by: Peter Wu pe...@lekensteyn.nl Tested-by: Peter Wu pe...@lekensteyn.nl Signed-off-by: Benjamin Tissoires benjamin.tissoi

Re: [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

On Tuesday 16 December 2014 09:33:44 Benjamin Tissoires wrote: > Hi Peter, > > On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu wrote: > > Devices speaking HID++ 2.0 report a different error code (0xff). Detect > > these errors too to avoid 5 second delays when the device reports

Re: [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

On Tuesday 16 December 2014 09:33:44 Benjamin Tissoires wrote: Hi Peter, On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu pe...@lekensteyn.nl wrote: Devices speaking HID++ 2.0 report a different error code (0xff). Detect these errors too to avoid 5 second delays when the device reports an error

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

17 December 2014 00:33:55 Peter Wu wrote: > On Tuesday 16 December 2014 17:06:01 Benjamin Tissoires wrote: > > If wtp_connect() fails, that means most of the time that the device has > > been disconnected. Subsequent attempts to contact the device will fail > > too, so it'

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

Hi Benjamin, On Tuesday 16 December 2014 17:13:05 Benjamin Tissoires wrote: > the logitech patches are queuing up really fast. > To keep track of them, I made a bundle on patchwork: > https://patchwork.kernel.org/bundle/bentiss/hid-logitech-hidpp/ > (/me discovered a new tool to play with) > >

Re: [PATCH 2/2] HID: logitech-hidpp: store the name of the device in struct hidpp

ets the pointer to an array (hdev->name). Defence in depth I guess, but perhaps a comment could clarify this? Otherwise the changes look OK. I have tested this situation: 1. Insert receiver 2. Return a HID++ version for the WTP. 3. Return -9 (ResourceError) for the devi

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

n 0; "0" is success, what about -1 or -ENODEV here to signal an error? The following line (in hidpp_connect_event) returns on !connected, but that is no reason to return 0 here. ("No connection" sounds like an error condition to me as "[wtp_]connect" cannot do something meaningf

[PATCH 3/3] HID: logitech-hidpp: separate HID++ from WTP processing

e-specific event processing. Suggested-by: Benjamin Tissoires Signed-off-by: Peter Wu Reviewed-by: Benjamin Tissoires --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check patch. Restructured code. v3: renamed var r to ret for consistency,

[PATCH v2 2/3] HID: logitech-hidpp: check WTP report length

Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length for WTP reports is valid to avoid reading out of bounds. Signed-off-by: Peter Wu --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check

[PATCH v2 1/3] HID: logitech-dj: check report length

Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length is valid to avoid reading out of bounds. Signed-off-by: Peter Wu --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check patch

[PATCH v2 3/3] HID: logitech-hidpp: separate HID++ from WTP processing

e-specific event processing. Suggested-by: Benjamin Tissoires Signed-off-by: Peter Wu --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check patch. Restructured code. --- drivers/hid/hid-logitech-hidpp.c | 18 -- 1 file changed, 12

Re: [PATCH 2/3] HID: logitech-{dj,hidpp}: check report length

On Tuesday 16 December 2014 09:53:07 Benjamin Tissoires wrote: > On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu wrote: > > Malicious USB devices can send bogus reports smaller than the expected > > buffer size. Ensure that the length is valid to avoid reading out of > > bounds. &g

Re: [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

On Tuesday 16 December 2014 09:33:44 Benjamin Tissoires wrote: > On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu wrote: > > Devices speaking HID++ 2.0 report a different error code (0xff). Detect > > these errors too to avoid 5 second delays when the device reports an > > err

Re: [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

On Tuesday 16 December 2014 09:33:44 Benjamin Tissoires wrote: On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu pe...@lekensteyn.nl wrote: Devices speaking HID++ 2.0 report a different error code (0xff). Detect these errors too to avoid 5 second delays when the device reports an error. Caught

Re: [PATCH 2/3] HID: logitech-{dj,hidpp}: check report length

On Tuesday 16 December 2014 09:53:07 Benjamin Tissoires wrote: On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu pe...@lekensteyn.nl wrote: Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length is valid to avoid reading out of bounds

[PATCH v2 3/3] HID: logitech-hidpp: separate HID++ from WTP processing

processing. Suggested-by: Benjamin Tissoires benjamin.tissoi...@redhat.com Signed-off-by: Peter Wu pe...@lekensteyn.nl --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check patch. Restructured code. --- drivers/hid/hid-logitech-hidpp.c | 18

[PATCH v2 1/3] HID: logitech-dj: check report length

Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length is valid to avoid reading out of bounds. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length

[PATCH v2 2/3] HID: logitech-hidpp: check WTP report length

Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length for WTP reports is valid to avoid reading out of bounds. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original

[PATCH 3/3] HID: logitech-hidpp: separate HID++ from WTP processing

processing. Suggested-by: Benjamin Tissoires benjamin.tissoi...@redhat.com Signed-off-by: Peter Wu pe...@lekensteyn.nl Reviewed-by: Benjamin Tissoires benjamin.tissoi...@redhat.com --- v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length v2: splitted original report length check patch

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

(in hidpp_connect_event) returns on !connected, but that is no reason to return 0 here. (No connection sounds like an error condition to me as [wtp_]connect cannot do something meaningful.) Whether or not you change the return value is up to you. This patch is Reviewed-by: Peter Wu pe...@lekensteyn.nl Kind regards

Re: [PATCH 2/2] HID: logitech-hidpp: store the name of the device in struct hidpp

name feature request (via the QEMU emulation). 4. Observe that this fails. So maybe you could add a comment for the above and add these tags: Reviewed-by: Peter Wu pe...@lekensteyn.nl Tested-by: Peter Wu pe...@lekensteyn.nl Kind regards, Peter + name = hidpp_get_device_name

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

Hi Benjamin, On Tuesday 16 December 2014 17:13:05 Benjamin Tissoires wrote: the logitech patches are queuing up really fast. To keep track of them, I made a bundle on patchwork: https://patchwork.kernel.org/bundle/bentiss/hid-logitech-hidpp/ (/me discovered a new tool to play with) Right

Re: [PATCH 1/2] HID: logitech-hidpp: bail out if wtp_connect fails

17 December 2014 00:33:55 Peter Wu wrote: On Tuesday 16 December 2014 17:06:01 Benjamin Tissoires wrote: If wtp_connect() fails, that means most of the time that the device has been disconnected. Subsequent attempts to contact the device will fail too, so it's simpler to bail out earlier

[PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

no functional difference. Signed-off-by: Peter Wu --- drivers/hid/hid-logitech-hidpp.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 2f420c0..ae23dec 100644 --- a/drivers/hid/hid-logitech

[PATCH 0/3] HID: logitech-{dj,hidpp}: more reliability fixes

ngth check was already missing in older kernels). Kind regards, Peter Peter Wu (3): HID: logitech-hidpp: detect HID++ 2.0 errors too HID: logitech-{dj,hidpp}: check report length HID: logitech-hidpp: avoid unintended fall-through drivers/hid/hid-logitech-dj.c| 16 +++- drivers/hid/hi

[PATCH 2/3] HID: logitech-{dj,hidpp}: check report length

). Signed-off-by: Peter Wu --- Hi, If you know that the WTP report (ID 2) has a length of 2, then you can change "<" to "!=" and remove the paragraph from the commit message. Kind regards, Peter --- drivers/hid/hid-logitech-dj.c| 16 +++- drivers/hid/hi

[PATCH 3/3] HID: logitech-hidpp: avoid unintended fall-through

Add a return to avoid a fall-through. Introduced in commit 57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad"). Signed-off-by: Peter Wu --- drivers/hid/hid-logitech-hidpp.c | 1 + 1 file changed, 1 insertion(+)

[PATCH 3/3] HID: logitech-hidpp: avoid unintended fall-through

Add a return to avoid a fall-through. Introduced in commit 57ac86cf52e903d9e3e0f12b34c814cce6b65550 (HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad). Signed-off-by: Peter Wu pe...@lekensteyn.nl --- drivers/hid/hid-logitech-hidpp.c | 1 + 1 file changed, 1 insertion

[PATCH 0/3] HID: logitech-{dj,hidpp}: more reliability fixes

missing in older kernels). Kind regards, Peter Peter Wu (3): HID: logitech-hidpp: detect HID++ 2.0 errors too HID: logitech-{dj,hidpp}: check report length HID: logitech-hidpp: avoid unintended fall-through drivers/hid/hid-logitech-dj.c| 16 +++- drivers/hid/hid-logitech

[PATCH 2/3] HID: logitech-{dj,hidpp}: check report length

). Signed-off-by: Peter Wu pe...@lekensteyn.nl --- Hi, If you know that the WTP report (ID 2) has a length of 2, then you can change to != and remove the paragraph from the commit message. Kind regards, Peter --- drivers/hid/hid-logitech-dj.c| 16 +++- drivers/hid/hid-logitech

[PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too

no functional difference. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- drivers/hid/hid-logitech-hidpp.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 2f420c0..ae23dec 100644 --- a/drivers

Re: [PATCH v2] HID: logitech-hidpp: prefix the name with Logitech

er. > > Signed-off-by: Benjamin Tissoires Reviewed-by: Peter Wu I have not tested this one, but the approach looks correct. What I have also been thinking of is the possibility that Logitech adds "LOGITECH" or "Logicool" (the Japanese trademark) before devices, but I t

Re: [PATCH v2] HID: logitech-hidpp: prefix the name with Logitech

benjamin.tissoi...@redhat.com Reviewed-by: Peter Wu pe...@lekensteyn.nl I have not tested this one, but the approach looks correct. What I have also been thinking of is the possibility that Logitech adds LOGITECH or Logicool (the Japanese trademark) before devices, but I think that is unlikely so

Re: [PATCH 4/4] HID: logitech-hidpp: disable io in probe error path

On Thursday 11 December 2014 09:37:06 Andrew de los Reyes wrote: > On Thu Dec 11 2014 at 7:31:43 AM Benjamin Tissoires > wrote: > > > > On Dec 11 2014 or thereabouts, Peter Wu wrote: > > > Balance a hid_device_io_start() call with hid_device_io_stop() in the &g

Re: [PATCH 2/2] HID: logitech-hidpp: prefix the name with Logitech

On Wednesday 10 December 2014 18:17:40 Benjamin Tissoires wrote: > On Dec 11 2014 or thereabouts, Peter Wu wrote: > > On Wednesday 10 December 2014 17:21:10 Benjamin Tissoires wrote: > > > Current names are reported as "K750", "M705", and it can be mislead

[PATCH 2/4] HID: logitech-hidpp: check name retrieval return code

ise result in an infinite loop.) Signed-off-by: Peter Wu --- drivers/hid/hid-logitech-hidpp.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 5066df8..4d72c20 100644 --- a/drivers/hid/hid-logit

[PATCH 3/4] HID: logitech-hidpp: add boundary check for name retrieval

The HID response has a limited size. Do not trust the value returned by hardware, check that it really fits in the message. Signed-off-by: Peter Wu --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid

[PATCH 4/4] HID: logitech-hidpp: disable io in probe error path

ort(). hid_set_drvdata() is called before wtp_allocate, be consistent and clear drvdata too on the error path of wtp_allocate. Signed-off-by: Peter Wu --- Hi Andrew, There are few users of hid_device_io_start/stop, this is the first one to get start/stop out of sync. Should the comment of hid_device_io_st

[PATCH 1/4] HID: logitech-hidpp: do not return the name length

We do not make any use of the actual name length get through hidpp_get_device_name(). Original patch by Benjamin Tissoires, this patch also replaces a (now) unnecessary goto by return NULL. Signed-off-by: Peter Wu --- drivers/hid/hid-logitech-hidpp.c | 19 ++- 1 file changed, 6

[PATCH 0/4] HID: logitech-hidpp: fixes for error conditions

are powered off and one M525 is active. evbug registers mouse events. Kind regards, Peter Peter Wu (4): HID: logitech-hidpp: do not return the name length HID: logitech-hidpp: check name retrieval return code HID: logitech-hidpp: add boundary check for name retrieval HID: logitech-hidpp

About "HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad"

Hi Benjamin, In commit 57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad") which is in jikos/hid, you made this change to wtp_raw_event: switch (data[0]) { case 0x02: - if (size < 21) -

About HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad

Hi Benjamin, In commit 57ac86cf52e903d9e3e0f12b34c814cce6b65550 (HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad) which is in jikos/hid, you made this change to wtp_raw_event: switch (data[0]) { case 0x02: - if (size 21) -

[PATCH 0/4] HID: logitech-hidpp: fixes for error conditions

are powered off and one M525 is active. evbug registers mouse events. Kind regards, Peter Peter Wu (4): HID: logitech-hidpp: do not return the name length HID: logitech-hidpp: check name retrieval return code HID: logitech-hidpp: add boundary check for name retrieval HID: logitech-hidpp

[PATCH 1/4] HID: logitech-hidpp: do not return the name length

We do not make any use of the actual name length get through hidpp_get_device_name(). Original patch by Benjamin Tissoires, this patch also replaces a (now) unnecessary goto by return NULL. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- drivers/hid/hid-logitech-hidpp.c | 19

[PATCH 3/4] HID: logitech-hidpp: add boundary check for name retrieval

The HID response has a limited size. Do not trust the value returned by hardware, check that it really fits in the message. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b

[PATCH 4/4] HID: logitech-hidpp: disable io in probe error path

(). hid_set_drvdata() is called before wtp_allocate, be consistent and clear drvdata too on the error path of wtp_allocate. Signed-off-by: Peter Wu pe...@lekensteyn.nl --- Hi Andrew, There are few users of hid_device_io_start/stop, this is the first one to get start/stop out of sync. Should the comment

  1   2   3   >