e:
*has_pr3 = 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
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
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
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:
>
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 will
)
drm_framebuffer_remove(fb_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 callb
/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
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:
&
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
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(+)
>
> (if you 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 w
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
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:
&
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 actua
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
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,
> >>
> &
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
d stuff.)
I understood that Roland's 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
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
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
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_susp
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
api before 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..b8b08
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
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 execu
-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/wir
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
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 the
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
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
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-off-by: Be
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
esday 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, s
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)
>
> Ri
ULL? probe sets 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
rn 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 mea
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, ad
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
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
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
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
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
> > error.
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
ength 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/h
).
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
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(+)
di
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
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
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
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
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
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_start()
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
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
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)
-
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_dev
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 device
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
>
> ---
> drivers/hid/hid-logitech-hidpp.c
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=6364
(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
> Reviewed-by: Peter Wu
> ---
> drivers/stag
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 fo
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 itsel
y matches the available types.
With that, you can add my
Reviewed-by: Peter Wu
(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
for exam
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. Ke
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
lis
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
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 details:
(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 sh
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 p
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 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
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,
https://github.com/Lekensteyn/aur/blob/1d1950
l it be problematic if the same tasklet gets executed multiple times (if
that is possible?).
Does it really need that much locking? dw_mmc.c also implements pre_req, but
uses tasklets without needing to lock anything.
Kind regards,
Peter
[1]: http://www.makelinux.net/ldd3/chp-7-sect-5
On Friday 1
Hi!
On Wednesday 16 April 2014 09:38:44 micky_ch...@realsil.com.cn wrote:
> From: Micky Ching
>
> 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() is called during pcr
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 e
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 wrote:
> [skip]
>
> > When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the
>
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
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 01/
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
> > w
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
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 22 --
drive
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
^
CC [M] 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/rtl81
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
>
> NACK - at least for now. This patch has merge conflicts for th
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-&g
la.kernel.org/show_bug.cgi?id=60713
---
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/wireles
d). Before 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
Signed-off-by: Peter Wu
---
drivers/net/wireless/rtlwifi/core.c | 52 +
1 file changed, 30 in
Unused as configure_filter takes care of setting/clearing RCR_AAP.
Signed-off-by: Peter Wu
---
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 20
drivers/net/wireless/rtlwifi/rtl8188ee/hw.h | 2 --
drivers/net/wireless/rtlwifi/rtl8188ee/sw.c | 1 -
drivers/net/wireless
cessed 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
---
drivers/net/wireless/rtlwifi/rtl
evice on
> > > resume?
> >
> > 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 th
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
> > Date: Tue Jul 16 22:10:35 2013 +0200
> >
> >
> > ACPI / hotplug / PCI:
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_d
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:
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.
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:
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 outpu
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;
> > k
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
> > t
ry leak also present here since dev_set_drvdata() always tries 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 kmemle
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 s
1 - 100 of 122 matches
Mail list logo
