On Friday 01 February 2013 22:44:55 Rafael J. Wysocki wrote:
On Friday, February 01, 2013 07:23:52 PM Peter Wu wrote:
On Thursday 31 January 2013 23:32:40 Rafael J. Wysocki wrote:
In general, for ACPI device power management to work, the initial
power states of devices must be known
On Friday 01 February 2013 22:44:55 Rafael J. Wysocki wrote:
On Friday, February 01, 2013 07:23:52 PM Peter Wu wrote:
On Thursday 31 January 2013 23:32:40 Rafael J. Wysocki wrote:
In general, for ACPI device power management to work, the initial
power states of devices must be known
On Wednesday 23 January 2013 20:12:59 Rafael J. Wysocki wrote:
On Wednesday, January 23, 2013 08:00:31 PM Peter Wu wrote:
Hi,
Any progress on this one? I guess it won't make into 3.8, perhaps 3.9?
No, that doesn't go anywhere for now.
In fact, I need to discuss that with Len
that provide _PS0/_PS3 without _PSC for some devices.
Verified to work on my HP nx6325 that has this problem.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Tested-by: Peter Wu lekenst...@gmail.com
I applied it on top of branch linux-next of repo linux-pm.
Fixes the issue I had
Hi,
Any progress on this one? I guess it won't make into 3.8, perhaps 3.9?
On Friday 04 January 2013 00:44:16 Rafael J. Wysocki wrote:
On Thursday, January 03, 2013 04:00:55 PM Bjorn Helgaas wrote:
On Thu, Jan 3, 2013 at 3:38 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, January
Hi,
While debugging upowerd (with Logitech Unifying receiver via hidraw),
I came across this list corruption warning. It probably has something
to do with me removing the receiver and re-inserting it while the file
descriptor to /dev/hidraw0 was still open. journalctl excerpt is on the
bottom of
On Wednesday 07 August 2013 03:01:26 Jiri Kosina wrote:
On Tue, 6 Aug 2013, Peter Wu wrote:
While debugging upowerd (with Logitech Unifying receiver via hidraw),
I came across this list corruption warning.
Peter,
does the patch below fix the problem you are seeing?
That one is already
From: Peter Wu lekenst...@gmail.com
This solves a BUG followed by a lockup in the following case:
1. Connect device and look in dmesg for the address:
[ 40.034520] usb 6-2: Product: My Passport 0748
2. Write something:
dd if=/dev/zero of=/dev/sdd bs=1M
3. Remove device:
echo 1
On Monday 19 August 2013 19:02:40 Tejun Heo wrote:
On Tue, Aug 20, 2013 at 12:45:53AM +0200, Peter Wu wrote:
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 68851ff..6e38a8b 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1007,7 +1007,8 @@ void bdi_writeback_workfn
On Friday 09 August 2013 11:31:15 Jiri Kosina wrote:
On Mon, 22 Jul 2013, Manoj Chourasia wrote:
This is mail is in regard to your commit for hidaw devices. We were
seeing kernel crashes while connect and disconnect a hidraw device and
we were hitting rb tree corruption in vmalloc and
On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote:
On 08/12/2013 05:54 PM, Peter Wu wrote:
On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
Before we revert to using the workaround, I'd like to suggest that
this new hidden problem may be an interaction with the xhci_hcd host
Hi,
I hit a BUG followed by a lockup when trying to wipe a new external USB 3.0
1TB 2.5 Western Digital My Passport (WDBBEP0010BBK-EESN) HDD.
The following command is used (with sudo):
dd if=/dev/zero of=/dev/sdd bs=1M
In another shell, I kept sending a USR1 signal to watch progress (maybe
Hi,
When I tried to build v3.11-rc1-8-g47188d3 out-of-tree, I get an error about a
missing asm/unistd_64.h file. The full build output (`git clean -xfd` was ran
before baking the kernel):
/home/me/Linux-src/build$ make O=$PWD -C ../linux -j8
make: Entering directory `/home/me/Linux-src/linux'
/generated/
Somehow that directory got root owned and I was unable to remove it without
using root power. After removing it, the build completes succesfully.
Sorry for the noise!
Thanks,
Peter
Peter Wu lekenst...@gmail.com wrote:
Hi,
When I tried to build v3.11-rc1-8-g47188d3 out-of-tree, I get
Hi,
I think I also encountered this similar issue after resume (and possibly a
real deadlock yesterday before/during suspend?). One message:
[ 71.204848] ==
[ 71.204850] [ INFO: possible circular locking dependency detected ]
[ 71.204852]
Hi,
On Wednesday 13 November 2013 16:11:47 Dave Jones wrote:
Hey Al,
here's another one..
[..]
I also saw this warning with a slightly different path.
Kernel is v3.12-7033-g42a2d92, the out-of-tree module below is unrelated
(bbswitch).
This was triggered when trying trying to get a
Hi Al,
Somewhere in the merge window of 3.13, coredumps appear truncated.
Instead of 319488 bytes, I get 868 bytes (tested with x86_64 only).
The latest Linus' master (v3.12-9579-g049ffa8) is still affected.
Bisection leads to:
commit 22a8cb8248ba5d340307ba72432253b1dbdb5cf7
Author: Al Viro
On Friday 15 November 2013 20:38:38 Al Viro wrote:
On Fri, Nov 15, 2013 at 03:26:10PM +0100, Peter Wu wrote:
Hi Al,
Somewhere in the merge window of 3.13, coredumps appear truncated.
Instead of 319488 bytes, I get 868 bytes (tested with x86_64 only).
The latest Linus' master (v3.12
directly. For rtl8192ce, there is still no change because
nothing modifies REG_RCR or receive_config. For rtl8192cu, it now also
applies changes to rx_conf from configure_filter, but that can be
considered a bug which is fixed later.
Signed-off-by: Peter Wu lekenst...@gmail.com
---
drivers/net/wireless
Unused as configure_filter takes care of setting/clearing RCR_AAP.
Signed-off-by: Peter Wu lekenst...@gmail.com
---
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 20
drivers/net/wireless/rtlwifi/rtl8188ee/hw.h | 2 --
drivers/net/wireless/rtlwifi/rtl8188ee/sw.c | 1
---
Peter Wu (3):
rtlwifi: avoid accessing RCR directly
rtlwifi: properly apply filter flags
rtlwifi: remove unused allow_all_destaddr functions
drivers/net/wireless/rtlwifi/core.c | 52 +
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 25
this patch, `iw wlan0 set monitor
otherbss` did not capture frames from other BSS's. After this patch, it
does print packets.
Tested-by: Peter Wu lekenst...@gmail.com
Signed-off-by: Peter Wu lekenst...@gmail.com
---
drivers/net/wireless/rtlwifi/core.c | 52 +
1
On Friday 14 February 2014 15:28:44 Larry Finger wrote:
On 02/14/2014 12:03 PM, Peter Wu wrote:
The rtl*_set_check_bssid functions are mostly the same, but access the
RCR register in different ways. Use the get_hw_reg abstraction layer
(which reads rtlpci-receive_config for PCI devices
On Friday 14 February 2014 15:38:32 Larry Finger wrote:
On 02/14/2014 12:03 PM, Peter Wu wrote:
Unused as configure_filter takes care of setting/clearing RCR_AAP.
Signed-off-by: Peter Wu lekenst...@gmail.com
NACK - at least for now. This patch has merge conflicts for the set of
patches
?
That is possible. Actually even quite likely, but let's wait for the
response from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
Tested-by: Peter Wu lekenst...@gmail.com
This works, the devices
] drivers/staging/rtl8821ae/rtl8821ae/hal_bt_coexist.o
Thanks,
Peter
Peter Wu (3):
rtlwifi: remove unused allow_all_destaddr functions
staging/rtl8821ae: avoid accessing RCR directly
staging/rtl8821ae: remove unused allow_all_destaddr function
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
Unused as configure_filter takes care of setting/clearing RCR_AAP.
In commit rtlwifi: rtl8723be: rtl8723com: Remove unused
allow_all_destaddr functions, Larry Finger removed allow_all_destaddr
from the struct. This commit removes the related function too.
Signed-off-by: Peter Wu pe
Similar to rtlwifi: avoid accessing RCR directly, this patch avoids
accessing receive_config directly and uses get_hw_reg. There is no
functional change.
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 5 +++--
1 file changed, 3 insertions(+), 2
Similar to commit rtlwifi: remove unused allow_all_destaddr functions,
this patch removes an unused function.
Unused as configure_filter takes care of setting/clearing RCR_AAP.
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 22
On Thursday 20 March 2014 14:48:22 Larry Finger wrote:
On 03/20/2014 01:52 PM, Peter Wu wrote:
Hi,
The first patch of these series was NAKed some weeks ago because it would
conflict with the new rtl8723be driver. Since those changes are in
wireless-next now, I have adjusted that patch
Hi,
While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in
intel_pmu_lbr_reset():
[0.024000] general protection fault: [#1]
[0.024000] CPU: 0 PID: 1 Comm: swapper Not tainted
3.14.0-rc7-qemu-00059-g08edb33 #14
[0.024000] Hardware name: Bochs Bochs, BIOS Bochs
cc'ing kvm people and list.
On Friday 21 March 2014 18:42:40 Peter Wu wrote:
Hi,
While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in
intel_pmu_lbr_reset():
[0.024000] general protection fault: [#1]
[0.024000] CPU: 0 PID: 1 Comm: swapper Not tainted
On Saturday 22 March 2014 10:50:45 Gleb Natapov wrote:
On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh Srinivas wrote:
On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote:
[skip]
When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the
guest
On Saturday 22 March 2014 14:27:59 Gleb Natapov wrote:
but now I have a NULL dereference (in rapl_pmu_init). Previously, when
`-cpu SandyBridge` was passed to qemu, it would show this:
[0.016995] Performance Events: unsupported p6 CPU model 42 no PMU
driver, software events
Hi,
On Tuesday 20 August 2013 09:33:08 Tejun Heo wrote:
On Tue, Aug 20, 2013 at 12:13:58PM +0200, Peter Wu wrote:
...
Hmmm... bdi-dev is cleared after bdi_wb_shutdown() so the work item
should no longer be running. It seems like something is queueing the
work item after shutdown
On Saturday 07 June 2014 16:30:19 Rickard Strandqvist wrote:
Expression '(X 0xfc) == 0x3' is always false
While this is true, I believe that some other mistake is made.
I chose to remove this code, because it will not make any difference.
But obviously it is rather a properly designed if
On Saturday 07 June 2014 19:01:20 Larry Finger wrote:
As you have learned here, automatically making changes suggested by some tool
may convert a visible bug into one that is invisible, and only found by a
detailed line-by-line examination of the code, and that is unlikely to
happen.
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Well, Larry is the maintainer, so he will ultimately pick up
(Please do not top-post.)
On Sunday 08 June 2014 22:47:31 Rickard Strandqvist wrote:
I found this error in some of the files. And after discussion with
Larry Finger and Peter Wu, it was decided that all files with this if
statement should change.
But of course I should update the comment
Hi,
I do not often suspend my laptop with a device inserted on the USB 3.0
port, but when I did last night, it trigged an immediate wake up. Not
only that, but after resume, some kworkers were hogging CPU. Another
problem is that the laptop overheats in some cases (see end of mail).
Some
On Tuesday 10 June 2014 23:31:37 Rickard Strandqvist wrote:
I guess it's ok to do the patches?
Right, you got some feedback from me and another person. You can
send patches whenever you like.
But then again, I will then send them one by one, with the cover
letter? +35 email?
Have you seen my
On Saturday 14 June 2014 15:24:32 Rickard Strandqvist wrote:
I found a logical error in an if statement that always evaluates to false.
This has after same discussion resulted in that we add a macro to handle this.
This commit message is useless. If you really need to refer to a mailing
list
On Monday 16 June 2014 16:52:45 Don Zickus wrote:
On Mon, Jun 16, 2014 at 04:12:44PM +0200, Peter Wu wrote:
Hi,
Writing to /proc/sys/kernel/watchdog_thresh causes the following BUG in
at least v3.13-rc2-625-g06151db, v3.15 and v3.16-rc1. Kernel config is
attached
On Wednesday 07 August 2013 15:34:08 Jiri Kosina wrote:
On Wed, 7 Aug 2013, Peter Wu wrote:
[..]
I have applied Manoj's patch[1] on top of 3.11-rc4 which seem to fix the
issue. One observation is that the new device is named /dev/hidraw1
instead of /dev/hidraw0. Example:
f(){ hidraw
On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
Before we revert to using the workaround, I'd like to suggest that
this new hidden problem may be an interaction with the xhci_hcd host
controller driver only.
Looking at the related bug, the OP indicates the machine only has
USB3 ports.
Hi!
On Wednesday 16 April 2014 09:38:44 micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
To avoid dead lock, we need make sure host-lock is always acquire
before pcr-lock. But in irq handler, we acquired pcr-lock in rtsx mfd
driver, and sd_isr_done_transfer()
-sect-5
On Friday 18 April 2014 16:00:53 Peter Wu wrote:
On Wednesday 16 April 2014 09:38:44 micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
To avoid dead lock, we need make sure host-lock is always acquire
before pcr-lock. But in irq handler, we acquired pcr
Hi!
When comparing the x86_64 assembly implementation (module aes-x86_64) against
the generic AES implementation, I found that the generic implementation was
consistenly faster.
Test setup #1:
* cryptsetup 1.6.4
* Linux v3.15-rc1-356-gebfc45e,
On Monday 23 June 2014 23:48:16 Rickard Strandqvist wrote:
An error was found in many rtlwifi drivers where an invalid mask was used,
(bt_msr 0xfc) will never match 0x3. This has been corrected by supplying
a valid mask as a macro. Drivers which did not have this bug are still
modified for
(staging drivers are handled by Greg KH, cc'ing him)
On Tuesday 24 June 2014 00:11:51 Rickard Strandqvist wrote:
For consistency with other drivers, replace a magic number by a macro.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Reviewed-by: Peter Wu pe
the available types.
With that, you can add my
Reviewed-by: Peter Wu pe...@lekensteyn.nl
(oh, and please mail me at @lekensteyn.nl for patches)
Also, when using a cover letter, you are supposed to group your changes. Not
add a single commit to each cover letter. If you made three sequential changes
On Saturday 21 June 2014 23:03:42 Rickard Strandqvist wrote:
I found a logical error in an if statement that always evaluates to false.
This has after same discussion resulted in that we add a macro to handle this.
See other mail, this subject and commit message still suck. The change itself
after successful memory
allocation, before reaching any error paths.
References: http://lkml.org/lkml/2013/1/23/191
Reported-by: Martin Mokrejs mmokr...@fold.natur.cuni.cz
Tested-by: Peter Wu lekenst...@gmail.com [ACPI conflict error path]
Signed-off-by: Peter Wu lekenst...@gmail.com
---
Hi Jean
and replacing i2c_get_adapdata(adapter) by
pci_get_drvdata(adapter-pci_dev) on top of this patch? I am not
sure what the purpose is for i2c_set_adapdata, hence this question.
Regards,
Peter
On Monday 23 December 2013 10:39:38 Peter Wu wrote:
The driver-specific data for i801 was only set
to
allocate memory?
Regards,
Peter
Peter Wu wrote:
Nevermind this patch, it does not really fix the memleak because
i2c_set_adapdata() calls dev_set_drvdata() which allocates memory.
(I must have ran kmemleak too early, right after boot it did not
give any warnings, now it does).
RFC: what
On Monday 23 December 2013 10:37:21 Alex Williamson wrote:
On Mon, 2013-12-23 at 16:49 +0100, Peter Wu wrote:
[..]
There is still one thing I do not fully understand, how should
dev_set_drvdata and dev_get_drvdata be used? For the devices passed
to probe functions, the core takes care
On Monday 23 December 2013 18:51:09 Alex Williamson wrote:
It does:
int device_private_init(struct device *dev)
{
dev-p = kzalloc(sizeof(*dev-p), GFP_KERNEL);
if (!dev-p)
return -ENOMEM;
dev-p-device = dev;
On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote:
I just used my Ethernet NIC for the first time on an up-to-date
Archlinux; it was working fine until I suspended to RAM: on resume the
Realtek/Ethernet device had completely disappeared.
The two entries absent from lspci output
On Friday 07 February 2014 00:48:14 Rafael J. Wysocki wrote:
On Friday, February 07, 2014 12:27:03 AM you wrote:
[...]
[ 49.170694] video LNXVIDEO:01: Restoring backlight state
[ 49.644845] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 49.646671] jme :04:00.5:
On Saturday 08 February 2014 16:01:36 Rafael J. Wysocki wrote:
It looks like we fail to resume the device, then, for some reason.
That may be a PCIe link issue or something similar.
Is this a regression for you? If so, what's the last kernel that didn't
have this problem? Does 3.13.y (as
On Sunday 09 February 2014 19:44:27 Bastien Traverse wrote:
You'll find them attached, but I got a strange error when I wanted to
run it as root:
$ sudo lspci -vv lspci_vv_before
pcilib: sysfs_read_vpd: read failed: Connection timed out
$ sudo -i
# lspci -vv
pcilib: sysfs_read_vpd: read
On Sunday 09 February 2014 22:46:05 Rafael J. Wysocki wrote:
That most likely would single out one of the ACPIPHP commits without giving
us much clue about what's going on.
I fail to see what the connection between those changes and system resume
is, however.
Please replace all pr_debug()
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
Could the following commit have something to do with it?
commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug
On Tuesday 23 September 2014 03:52:48 C Bergström wrote:
Here's where I originally found it
https://github.com/Bumblebee-Project/Bumblebee/issues/159
(Adding Peter to cc chain)
I guess there's already a bug id and some (snarky?) comments
https://bugzilla.kernel.org/show_bug.cgi?id=63641
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)
-
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
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
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
().
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
result in an infinite loop.)
Signed-off-by: Peter Wu pe...@lekensteyn.nl
---
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
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 misleading
for the users when they look at their input
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
benjamin.tissoi...@redhat.com wrote:
On Dec 11 2014 or thereabouts, Peter Wu wrote:
Balance a hid_device_io_start() call with hid_device_io_stop() in the
error path
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
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
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
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
).
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
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
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
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
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
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
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
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
(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
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
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
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
On Wednesday 10 December 2014 17:21:09 Benjamin Tissoires wrote:
We do not make any use of the actual name length get through
hidpp_get_device_name().
We can drop the extra code and simplify the API a bit.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---
On Wednesday 10 December 2014 17:21:10 Benjamin Tissoires wrote:
Current names are reported as K750, M705, and it can be misleading
for the users when they look at their input device list.
Prefixing the names with Logitech makes things better.
Doesn't this apply to all input devices? Like,
On Wednesday 10 December 2014 18:01:52 Benjamin Tissoires wrote:
On Dec 10 2014 or thereabouts, Peter Wu wrote:
On Wednesday 10 December 2014 17:21:09 Benjamin Tissoires wrote:
We do not make any use of the actual name length get through
hidpp_get_device_name().
We can drop
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
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
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>
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
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
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
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
-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
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
1 - 100 of 237 matches
Mail list logo
