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

[Peter Wu]

On Tue, Aug 27, 2019 at 05:13:21PM -0500, Bjorn Helgaas wrote:
> [+cc Peter, Mika, Dave]
> 
> https://lore.kernel.org/r/20190827134756.10807-1-kai.heng.f...@canonical.com
> 
> On Wed, Aug 28, 2019 at 12:58:28AM +0800, Kai-Heng Feng wrote:
> > at 23:25, Takashi Iwai  wrote:
> > > On Tue, 27 Aug 2019 15:47:55 +0200,
> > > Kai-Heng Feng wrote:
> > > > A driver may want to know the existence of _PR3, to choose different
> > > > runtime suspend behavior. A user will be add in next patch.
> > > > 
> > > > This is mostly the same as nouveau_pr3_present().
> > > 
> > > Then it'd be nice to clean up the nouveau part, too?
> > 
> > nouveau_pr3_present() may call pci_d3cold_disable(), and my intention is to
> > only check the presence of _PR3 (i.e. a dGPU) without touching anything.
> 
> It looks like Peter added that code with 279cf3f23870
> ("drm/nouveau/acpi: use DSM if bridge does not support D3cold").
> 
> I don't understand the larger picture, but it is somewhat surprising
> that nouveau_pr3_present() *looks* like a simple predicate with no
> side-effects, but in fact it disables the use of D3cold in some cases.

The reason for disabling _PR3 from that point on is because mixing the
ACPI firmware code that uses power resources (_PR3) with the legacy
_DSM/_PS0/_PS3 methods to manage power states could break as that
combination is unlikely to be supported nor tested by firmware authors.

If a user sets /sys/bus/pci/devices/.../d3cold_allowed to 0, then the
pci_d3cold_disable call ensures that this action is remembered and
prevents power resources from being used again.

For example, compare this power resource _OFF code:
https://github.com/Lekensteyn/acpi-stuff/blob/b55f6bdb/dsl/Clevo_P651RA/ssdt3.dsl#L454-L471

with this legacy _PS0/_PS3 code:
https://github.com/Lekensteyn/acpi-stuff/blob/b55f6bdb/dsl/Clevo_P651RA/ssdt7.dsl#L113-L142

The power resource code checks the "MSD3" variable to check whether a
transition to OFF is required while the legacy _PS3 checks "DGPS". The
sequence PG00._OFF followed by _DSM (to to change "OPCE") and _PS3 might
trigger some device-specific code twice and could lead to lockups
(infinite loops polling for power state) or worse. I am not sure if I
have ever tested this scenario however.

> If the disable were moved to the caller, Kai-Heng's new interface
> could be used both places.

Moving the pci_d3cold_disable call to the caller looks reasonable to me.
After the first patch gets merged, nouveau could use something like:

*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

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

[Peter Wu]

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 
---
 Documentation/trace/ftrace.rst | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index f60079259669..965be5c9afb3 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -125,7 +125,8 @@ of ftrace. Here is a list of some of the key files:
 
This file holds the output of the trace in a human
readable format (described below). Note, tracing is temporarily
-   disabled while this file is being read (opened).
+   disabled when the file is open for reading. Once all readers
+   are closed, tracing is re-enabled.
 
   trace_pipe:
 
@@ -139,8 +140,9 @@ of ftrace. Here is a list of some of the key files:
will not be read again with a sequential read. The
"trace" file is static, and if the tracer is not
adding more data, it will display the same
-   information every time it is read. This file will not
-   disable tracing while being read.
+   information every time it is read. Unlike the
+   "trace" file, opening this file for reading will not
+   temporarily disable tracing.
 
   trace_options:
 
@@ -3153,7 +3155,10 @@ different. The trace is live.
 
 
 Note, reading the trace_pipe file will block until more input is
-added.
+added. This is contrary to the trace file. If any process opened
+the trace file for reading, it will actually disable tracing and
+prevent new entries from being added. The trace_file file does
+not have this limitation.
 
 trace entries
 -
-- 
2.22.0

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

[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 5a766aaa8..51e3bd111 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -367,6 +367,14 @@ enum bpf_map_type {
 BPF_MAP_TYPE_DEVMAP,
 BPF_MAP_TYPE_SOCKMAP,
 BPF_MAP_TYPE_CPUMAP,
+BPF_MAP_TYPE_XSKMAP,
+BPF_MAP_TYPE_SOCKHASH,
+BPF_MAP_TYPE_CGROUP_STORAGE,
+BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
+BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
+BPF_MAP_TYPE_QUEUE,
+BPF_MAP_TYPE_STACK,
+/* See /usr/include/linux/bpf.h for the full list. */
 };
 .EE
 .in
@@ -756,6 +764,25 @@ enum bpf_prog_type {
 BPF_PROG_TYPE_KPROBE,
 BPF_PROG_TYPE_SCHED_CLS,
 BPF_PROG_TYPE_SCHED_ACT,
+BPF_PROG_TYPE_TRACEPOINT,
+BPF_PROG_TYPE_XDP,
+BPF_PROG_TYPE_PERF_EVENT,
+BPF_PROG_TYPE_CGROUP_SKB,
+BPF_PROG_TYPE_CGROUP_SOCK,
+BPF_PROG_TYPE_LWT_IN,
+BPF_PROG_TYPE_LWT_OUT,
+BPF_PROG_TYPE_LWT_XMIT,
+BPF_PROG_TYPE_SOCK_OPS,
+BPF_PROG_TYPE_SK_SKB,
+BPF_PROG_TYPE_CGROUP_DEVICE,
+BPF_PROG_TYPE_SK_MSG,
+BPF_PROG_TYPE_RAW_TRACEPOINT,
+BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+BPF_PROG_TYPE_LWT_SEG6LOCAL,
+BPF_PROG_TYPE_LIRC_MODE2,
+BPF_PROG_TYPE_SK_REUSEPORT,
+BPF_PROG_TYPE_FLOW_DISSECTOR,
+/* See /usr/include/linux/bpf.h for the full list. */
 };
 .EE
 .in
-- 
2.22.0

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

[Peter Wu]

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:
> > > > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
> > > > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
> > > > have some effect). After that, drm_fb_helper_initial_config is called
> > > > which may call the "fb_probe" driver callback.
> > > > 
> > > > This driver callback may call drm_fb_helper_defio_init (as is done by
> > > > drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
> > > > as documented. These are normally cleaned up on exit by
> > > > drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
> > > > 
> > > > If an error occurs after "fb_probe", but before setup is complete, then
> > > > calling just drm_fb_helper_fini will leak resources. This was triggered
> > > > by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
> > > > 
> > > >   [   50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to 
> > > > support this framebuffer
> > > >   [   50.009436] bochs-drm :00:02.0: 
> > > > [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set 
> > > > configuration (ret=-38)
> > > >   [   50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 
> > > > :00:02.0 on minor 2
> > > >   [   50.013604] WARNING: CPU: 1 PID: 1 at 
> > > > drivers/gpu/drm/drm_mode_config.c:477 
> > > > drm_mode_config_cleanup+0x280/0x2a0
> > > >   [   50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G   
> > > >  T 4.20.0-rc7 #1
> > > >   [   50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
> > > >   ...
> > > >   [   50.023155] Call Trace:
> > > >   [   50.023155]  ? bochs_kms_fini+0x1e/0x30
> > > >   [   50.023155]  ? bochs_unload+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 test robot 
> > > > Cc: Noralf Trønnes 
> > > > Signed-off-by: Peter Wu 
> > > > ---
> > > >drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index 9d64f874f965..432e0f3b9267 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device 
> > > > *dev,
> > > > return 0;
> > > >err_drm_fb_helper_fini:
> > > > -   drm_fb_helper_fini(fb_helper);
> > > > +   drm_fb_helper_fbdev_teardown(dev);
> > > 
> > > This change will break the error path for drm_fbdev_generic_setup()
> > > because drm_fb_helper_generic_probe() cleans up on error but doesn't
> > > clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
> > 
> > This should probably considered a bug of drm_fb_helper_generic_probe.
> > Ownership of fb_helper should remain with the caller. The caller can
> > detect an error and act accordingly.
> > 
> > > My assumption has been that the drm_fb_helper_funcs->fb_probe callback
> > > cleans up its resources on error. Clearly this is not the case for bochs, 
> > > so
> > > my take on this is that bochsfb_create() needs to clean up on error.
> > 
> > That assumption still holds for bochs. The problem is this sequence:
> > - drm_fb_helper_fbdev_setup is called.
> > - fb_probe succeeds (this is crucial).
> > - register_framebuffer fails.
> > - error path of setup is triggered.
> > 
> > As fb_helper is fully setup by drivers, the drm_fb_helper core should
> > fully deallocate it again on the error path or else a leak occurs.
>

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

[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
> > have some effect). After that, drm_fb_helper_initial_config is called
> > which may call the "fb_probe" driver callback.
> > 
> > This driver callback may call drm_fb_helper_defio_init (as is done by
> > drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
> > as documented. These are normally cleaned up on exit by
> > drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
> > 
> > If an error occurs after "fb_probe", but before setup is complete, then
> > calling just drm_fb_helper_fini will leak resources. This was triggered
> > by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
> > 
> >  [   50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support 
> > this framebuffer
> >  [   50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup] 
> > *ERROR* fbdev: Failed to set configuration (ret=-38)
> >  [   50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 
> > :00:02.0 on minor 2
> >  [   50.013604] WARNING: CPU: 1 PID: 1 at 
> > drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
> >  [   50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G
> > T 4.20.0-rc7 #1
> >  [   50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
> >  ...
> >  [   50.023155] Call Trace:
> >  [   50.023155]  ? bochs_kms_fini+0x1e/0x30
> >  [   50.023155]  ? bochs_unload+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 test robot 
> > Cc: Noralf Trønnes 
> > Signed-off-by: Peter Wu 
> > ---
> >   drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 9d64f874f965..432e0f3b9267 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
> > return 0;
> >   err_drm_fb_helper_fini:
> > -   drm_fb_helper_fini(fb_helper);
> > +   drm_fb_helper_fbdev_teardown(dev);
> 
> This change will break the error path for drm_fbdev_generic_setup()
> because drm_fb_helper_generic_probe() cleans up on error but doesn't
> clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().

This should probably considered a bug of drm_fb_helper_generic_probe.
Ownership of fb_helper should remain with the caller. The caller can
detect an error and act accordingly.

> My assumption has been that the drm_fb_helper_funcs->fb_probe callback
> cleans up its resources on error. Clearly this is not the case for bochs, so
> my take on this is that bochsfb_create() needs to clean up on error.

That assumption still holds for bochs. The problem is this sequence:
- drm_fb_helper_fbdev_setup is called.
- fb_probe succeeds (this is crucial).
- register_framebuffer fails.
- error path of setup is triggered.

As fb_helper is fully setup by drivers, the drm_fb_helper core should
fully deallocate it again on the error path or else a leak occurs.

> Gerd has a patchset that switches bochs over to the generic fbdev
> emulation, but ofc that doesn't help with 4.20:
> https://patchwork.freedesktop.org/series/54269/

And that does not help with other users of the drm_fb_helper who use
functions like drm_fb_helper_defio_init. They will likely run in the
same problem.

I don't have a way to test tinydrm or other drivers, but if you force
register_framebuffer to fail, you should be able to reproduce the
problem with drm_fb_helper_generic_probe.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

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

[Peter Wu]

fo);
}

info->par = &bochs->fb.helper;

fb = drm_gem_fbdev_fb_create(bochs->dev, sizes, 0, gobj, NULL);
if (IS_ERR(fb)) {
DRM_ERROR("Failed to create framebuffer: %ld\n", PTR_ERR(fb));
return PTR_ERR(fb);
}

/* setup helper */
bochs->fb.helper.fb = fb;

Note that "fb" is unhandled by "drm_fb_helper_fini", so it leaks.

What is the usual behavior? drm_fb_helper_fbdev_setup succeeds and on unload
drm_fb_helper_fbdev_teardown is called which properly releases "fb":

void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
{
struct drm_fb_helper *fb_helper = dev->fb_helper;
struct fb_ops *fbops = NULL;

if (!fb_helper)
return;

/* Unregister if it hasn't been done already */
if (fb_helper->fbdev && fb_helper->fbdev->dev)
drm_fb_helper_unregister_fbi(fb_helper);

if (fb_helper->fbdev && fb_helper->fbdev->fbdefio) {
fb_deferred_io_cleanup(fb_helper->fbdev);
kfree(fb_helper->fbdev->fbdefio);
fbops = fb_helper->fbdev->fbops;
}

drm_fb_helper_fini(fb_helper);
kfree(fbops);

if (fb_helper->fb)
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 callback
drm_fb_helper_funcs::fb_probe, detects an error but does not properly release
all resources from the callback even after calling "drm_fb_helper_fini". On
unload, "drm_fb_helper_fbdev_teardown" has no effect because the earlier call to
"drm_fb_helper_fini" and skips the required "drm_framebuffer_remove" call.

I'll send a proposed patch in a reply.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

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

[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
have some effect). After that, drm_fb_helper_initial_config is called
which may call the "fb_probe" driver callback.

This driver callback may call drm_fb_helper_defio_init (as is done by
drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
as documented. These are normally cleaned up on exit by
drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.

If an error occurs after "fb_probe", but before setup is complete, then
calling just drm_fb_helper_fini will leak resources. This was triggered
by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):

[   50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this 
framebuffer
[   50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup] 
*ERROR* fbdev: Failed to set configuration (ret=-38)
[   50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 
on minor 2
[   50.013604] WARNING: CPU: 1 PID: 1 at 
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
[   50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT 
4.20.0-rc7 #1
[   50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
...
[   50.023155] Call Trace:
[   50.023155]  ? bochs_kms_fini+0x1e/0x30
[   50.023155]  ? bochs_unload+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 test robot 
Cc: Noralf Trønnes 
Signed-off-by: Peter Wu 
---
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d64f874f965..432e0f3b9267 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
return 0;
 
 err_drm_fb_helper_fini:
-   drm_fb_helper_fini(fb_helper);
+   drm_fb_helper_fbdev_teardown(dev);
 
return ret;
 }
-- 
2.20.0

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

[Peter Wu]

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:
> > 
> > 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
> 
> Thanks for letting me know, both are now dropped.  Please let me and
> sta...@vger.kernel.org know when it is safe to add these back.

Patches entered mainline, please consider these patches for backporting
to 4.8:

1db4496f167b drm/amdgpu: fix power state when port pm is unavailable
d3ac31f3b4bf drm/radeon: fix power state when port pm is unavailable (v2)

7ac33e47d576 drm/amdgpu: fix check for port PM availability
bcfdd5d51050 drm/radeon: fix check for port PM availability

-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

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

[Peter Wu]

Hi Greg,

On Wed, Nov 30, 2016 at 10:29:51AM +0100, Greg Kroah-Hartman wrote:
> 4.8-stable review patch.  If anyone has any objections, please let me know.

Please delay this patch (amd tje mext radeon patch, 15/37), it contains
a regression for which these patches (from drm-fixes) are needed:

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 
> 
> commit 1db4496f167bcc7c6541d449355ade2e7d339d52 upstream.
> 
> When PCIe port PM is not enabled (system BIOS is pre-2015 or the
> pcie_port_pm=off parameter is set), legacy ATPX PM should still be
> marked as supported. Otherwise the GPU can fail to power on after
> runtime suspend. This affected a Dell Inspiron 5548.
> 
> Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
> where hybrid graphics platforms using power resources was introduced),
> but that seems more risky at this point and would not solve the
> pcie_port_pm=off issue.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
> Reported-and-tested-by: Nayan Deshmukh 
> Signed-off-by: Peter Wu 
> Signed-off-by: Alex Deucher 
> Acked-by: Christian König 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> @@ -33,6 +33,7 @@ struct amdgpu_atpx {
>  
>  static struct amdgpu_atpx_priv {
>   bool atpx_detected;
> + bool bridge_pm_usable;
>   /* handle for device - and atpx */
>   acpi_handle dhandle;
>   acpi_handle other_handle;
> @@ -200,7 +201,11 @@ static int amdgpu_atpx_validate(struct a
>   atpx->is_hybrid = false;
>   if (valid_bits & ATPX_MS_HYBRID_GFX_SUPPORTED) {
>   printk("ATPX Hybrid Graphics\n");
> - atpx->functions.power_cntl = false;
> + /*
> +  * Disable legacy PM methods only when pcie port PM is usable,
> +  * otherwise the device might fail to power off or power on.
> +  */
> + atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable;
>   atpx->is_hybrid = true;
>   }
>  
> @@ -471,6 +476,7 @@ static int amdgpu_atpx_power_state(enum
>   */
>  static bool amdgpu_atpx_pci_probe_handle(struct pci_dev *pdev)
>  {
> + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev);
>   acpi_handle dhandle, atpx_handle;
>   acpi_status status;
>  
> @@ -485,6 +491,7 @@ static bool amdgpu_atpx_pci_probe_handle
>   }
>   amdgpu_atpx_priv.dhandle = dhandle;
>   amdgpu_atpx_priv.atpx.handle = atpx_handle;
> + amdgpu_atpx_priv.bridge_pm_usable = parent_pdev && 
> parent_pdev->bridge_d3;
>   return true;
>  }
>  
> 
> 

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

[Peter Wu]

On Mon, Nov 21, 2016 at 03:52:20PM +0100, Adam Borowski wrote:
> Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
> modversion support for symbols exported from asm files. Architectures
> must include C-style declarations for those symbols in asm/asm-prototypes.h
> in order for them to be versioned.
> 
> Add these declarations for x86, and an architecture-independent file that
> can be used for common symbols.
> 
> User impact: kernels may fail to load modules at all when
> CONFIG_MODVERSIONS=y.
> 
> Signed-off-by: Adam 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(+)
>  create mode 100644 arch/x86/include/asm/asm-prototypes.h
>  create mode 100644 include/asm-generic/asm-prototypes.h
> 
> diff --git a/arch/x86/include/asm/asm-prototypes.h 
> b/arch/x86/include/asm/asm-prototypes.h
> new file mode 100644
> index 000..ae87224
> --- /dev/null
> +++ b/arch/x86/include/asm/asm-prototypes.h
> @@ -0,0 +1,12 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> diff --git a/include/asm-generic/asm-prototypes.h 
> b/include/asm-generic/asm-prototypes.h
> new file mode 100644
> index 000..df13637
> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include 
> +extern void *__memset(void *, int, __kernel_size_t);
> +extern void *__memcpy(void *, const void *, __kernel_size_t);
> +extern void *__memmove(void *, const void *, __kernel_size_t);
> +extern void *memset(void *, int, __kernel_size_t);
> +extern void *memcpy(void *, const void *, __kernel_size_t);
> +extern void *memmove(void *, const void *, __kernel_size_t);
> -- 
> 2.10.2
> 
> Now with a better description, provided by Nick Piggin (thanks!), and a
> remark about user impact.
> 
> This version doesn't split the patch between x86 vs generic parts, would you
> guys prefer that?

>From an observer POV: based on the git log include/asm-generic/
arch/x86/include/asm/, a split up seems quite common.

By the way, to make the description and discussion closer, you might
want to structure your mail like this:

[patch description]
---
[discussion]
---
[actual patch]

When applying the patch, the text after the first "---" is automatically
dropped.

Thanks!

Kind regards,
Peter

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

[Peter Wu]

On Mon, Nov 21, 2016 at 06:27:14PM +1100, Nicholas Piggin wrote:
> Hi Adam,
> 
> Thanks. I'd suggest doing x86: or x86/kbuild: prefix for the patch. Also
> possibly consider describing what the patch does at a higher level in your
> subject line, e.g.:
> 
>   x86/kbuild: enable modversions for symbols exported from asm
> 
> Also, it wouldn't hurt to add a little changelog of your own. Describe
> problem then solution, e.g.,
> 
>   Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
>   modversion support for symbols exported from asm files. Architectures
>   must include C-style declarations for those symbols in asm/asm-prototypes.h
>   in order for them to be versioned.
> 
>   Add these declarations for x86, and an architecture-independent file that
>   can be used for common symbols.
> 
> (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 worth to mention in the changelog the user impact,
namely that kernels may fail to load modules at all when
CONFIG_MODVERSIONS=y.

Kind regards,
Peter

> Also it's not a big deal, but if you redo the patch, you could consider
> splitting it into two (first add the generic header, then the x86 header),
> but both can go via the x86 tree.
> 
> Thanks,
> Nick
> 
> On Mon, 21 Nov 2016 07:39:45 +0100
> Adam Borowski  wrote:
> 
> > Nicholas Piggin wrote:
> > > Architectures will need to have an include/asm/asm-prototypes.h that
> > > defines or #include<>s C-style prototypes for exported asm functions.
> > > We can do an asm-generic version for the common ones like memset so
> > > there's not a lot of pointless duplication there.  
> > 
> > Signed-off-by: Adam Borowski 
> > Tested-by: Kalle Valo 
> > ---
> >  arch/x86/include/asm/asm-prototypes.h | 12 
> >  include/asm-generic/asm-prototypes.h  |  7 +++
> >  2 files changed, 19 insertions(+)
> >  create mode 100644 arch/x86/include/asm/asm-prototypes.h
> >  create mode 100644 include/asm-generic/asm-prototypes.h
> > 
> > diff --git a/arch/x86/include/asm/asm-prototypes.h 
> > b/arch/x86/include/asm/asm-prototypes.h
> > new file mode 100644
> > index 000..ae87224
> > --- /dev/null
> > +++ b/arch/x86/include/asm/asm-prototypes.h
> > @@ -0,0 +1,12 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > diff --git a/include/asm-generic/asm-prototypes.h 
> > b/include/asm-generic/asm-prototypes.h
> > new file mode 100644
> > index 000..df13637
> > --- /dev/null
> > +++ b/include/asm-generic/asm-prototypes.h
> > @@ -0,0 +1,7 @@
> > +#include 
> > +extern void *__memset(void *, int, __kernel_size_t);
> > +extern void *__memcpy(void *, const void *, __kernel_size_t);
> > +extern void *__memmove(void *, const void *, __kernel_size_t);
> > +extern void *memset(void *, int, __kernel_size_t);
> > +extern void *memcpy(void *, const void *, __kernel_size_t);
> > +extern void *memmove(void *, const void *, __kernel_size_t);
> 

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

[Peter Wu]

Hi Nicholas,

Current git master (v4.9-rc5-364-g77079b1) with the latest kbuild fixes
is still failing to load modules when built with CONFIG_MODVERSIONS=y on
x86_64 using GCC 6.2.1.

It can still be reproduced with make defconfig, then enabling
CONFIG_MODVERSIONS=y. The build output contains:

WARNING: "memcpy" [net/netfilter/nf_nat.ko] has no CRC!
WARNING: "memmove" [net/netfilter/nf_nat.ko] has no CRC!
WARNING: "_copy_to_user" [fs/efivarfs/efivarfs.ko] has no CRC!
WARNING: "memcpy" [fs/efivarfs/efivarfs.ko] has no CRC!
WARNING: "_copy_from_user" [fs/efivarfs/efivarfs.ko] has no CRC!

$ grep 00 Module.symvers
0x  phys_base   vmlinux EXPORT_SYMBOL
0x  memmove vmlinux EXPORT_SYMBOL
0x  __copy_user_nocache vmlinux EXPORT_SYMBOL
0x  __get_user_4vmlinux EXPORT_SYMBOL
0x  __put_user_4vmlinux EXPORT_SYMBOL
0x  __memcpyvmlinux EXPORT_SYMBOL
0x  memset  vmlinux EXPORT_SYMBOL
0x  __sw_hweight64  vmlinux EXPORT_SYMBOL
0x  __sw_hweight32  vmlinux EXPORT_SYMBOL
0x  memcpy_mcsafe_unrolled  vmlinux EXPORT_SYMBOL_GPL
0x  memcpy  vmlinux EXPORT_SYMBOL
0x  copy_user_enhanced_fast_string  vmlinux EXPORT_SYMBOL
0x  clear_page  vmlinux EXPORT_SYMBOL
0x  __put_user_2vmlinux EXPORT_SYMBOL
0x  __get_user_2vmlinux EXPORT_SYMBOL
0x  copy_page   vmlinux EXPORT_SYMBOL
0x  copy_user_generic_stringvmlinux EXPORT_SYMBOL
0x  _copy_to_user   vmlinux EXPORT_SYMBOL
0x  __memmove   vmlinux EXPORT_SYMBOL
0x  empty_zero_page vmlinux EXPORT_SYMBOL
0x  __get_user_8vmlinux EXPORT_SYMBOL
0x  __put_user_8vmlinux EXPORT_SYMBOL
0x  _copy_from_user vmlinux EXPORT_SYMBOL
0x  native_load_gs_indexvmlinux EXPORT_SYMBOL
0x  __memsetvmlinux EXPORT_SYMBOL
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
> Peter Wu  wrote:
> 
> > 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:
> > > > 
> > > > commit 784d5699eddc55878627da20d3fe0c8542e2f1a2
> > > > Author: Al Viro 
> > > > Date:   Mon Jan 11 11:04:34 2016 -0500  
> > > > > WARNING: "memset" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "__fentry__" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "memcpy" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "__sw_hweight32" [sound/usb/snd-usbmidi-lib.ko] has no CRC!  
> > > 
> > > Has any progress been made with this problem?
> > > 
> > > I'm also encountering it on my debian-unstable box on any kernel more 
> > > recent than 4.9-rc1 (up to and including 4.9-rc4).  I am glad someone 
> > > managed to isolate it as I was unable to get a clean bisect.
> > > 
> > > Vince  
> > 
> > The original kbuild issue went in via
> > merge commit 84d69848c97faab0c25aa2667b273404d2e2a64a which notes:
> > 
> >  - EXPORT_SYMBOL for asm source by Al Viro.
> > 
> >This does bring a regression, because genksyms no longer generates
> >checksums for these symbols (CONFIG_MODVERSIONS). Nick Piggin is
> >working on a patch to fix this.
> > 
> >Plus, we are talking about functions like strcpy(), which rarely
> >change prototypes.
> > 
> > Adding Nicholas in the cc, hopefully he can give a status update.
> 
> I think Michal has everything needed now for the kbuild bits. The arch
> specific patches can go via arch trees quite easily (there is no hard
> dependency either way). This is the kbuild bit:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mmarek/kbuild.git/commit/?h=rc-fixes&id=4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187
> 
> And it also needs this incremental bit not in Michal's tree yet:
> 
> ---
>  scripts/Makefile.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 3e223c2..05c6bb4 100644
> --- a

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

[Peter Wu]

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:
> > 
> > commit 784d5699eddc55878627da20d3fe0c8542e2f1a2
> > Author: Al Viro 
> > Date:   Mon Jan 11 11:04:34 2016 -0500
> > > WARNING: "memset" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > WARNING: "__fentry__" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > WARNING: "memcpy" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > WARNING: "__sw_hweight32" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> 
> Has any progress been made with this problem?
> 
> I'm also encountering it on my debian-unstable box on any kernel more 
> recent than 4.9-rc1 (up to and including 4.9-rc4).  I am glad someone 
> managed to isolate it as I was unable to get a clean bisect.
> 
> Vince

The original kbuild issue went in via
merge commit 84d69848c97faab0c25aa2667b273404d2e2a64a which notes:

 - EXPORT_SYMBOL for asm source by Al Viro.

   This does bring a regression, because genksyms no longer generates
   checksums for these symbols (CONFIG_MODVERSIONS). Nick Piggin is
   working on a patch to fix this.

   Plus, we are talking about functions like strcpy(), which rarely
   change prototypes.

Adding Nicholas in the cc, hopefully he can give a status update.

Kind regards,
Peter

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

[Peter Wu]

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 actual definitions

Signed-off-by: Al Viro 

Good builds have a non-zero address in Module.symvers:

0x69acdf38  memcpy  vmlinux EXPORT_SYMBOL

Bad builds have a zero address here:

0x  memcpy  vmlinux EXPORT_SYMBOL

This was encountered on Arch Linux with GCC 6.2.1 and
Linux v4.9-rc2-40-g9fe68ca. Note that the identified commit above cannot
be reverted cleanly on master.

Kind regards,
Peter

On Fri, Oct 21, 2016 at 06:23:57PM +0200, Oliver Hartkopp wrote:
> Hello Michal,
> 
> I waited some days for a fix - but obviously no one else has this problem so
> far ...
> 
> This merge
> 
> "Merge branch 'kbuild' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild"
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84d69848c97faab0c25aa2667b273404d2e2a64a
> 
> creates a bunch of warnings on my system and the built kernel does not boot
> (it complains about a missing root fs).
> 
> In the build process some .ko files are built fine and some don't:
> 
> (..)
>   MODPOST 176 modules
>   AS  arch/x86/boot/compressed/efi_thunk_64.o
>   GZIParch/x86/boot/compressed/vmlinux.bin.gz
>   CC  arch/x86/boot/compressed/misc.o
> WARNING: "memset" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> WARNING: "__fentry__" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> WARNING: "memcpy" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> WARNING: "__sw_hweight32" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> WARNING: "_copy_to_user" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "memset" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "__put_user_1" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "__put_user_4" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "__fentry__" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "memcpy" [sound/usb/snd-usb-audio.ko] has no CRC!
> WARNING: "__fentry__" [sound/soundcore.ko] has no CRC!
> (..)
> WARNING: "__fentry__" [arch/x86/crypto/crc32c-intel.ko] has no CRC!
> WARNING: "__fentry__" [arch/x86/crypto/crc32-pclmul.ko] has no CRC!
> WARNING: "__fentry__" [arch/x86/crypto/aesni-intel.ko] has no CRC!
> WARNING: "__fentry__" [arch/x86/crypto/aes-x86_64.ko] has no CRC!
>   CC  arch/x86/crypto/aes-x86_64.mod.o
>   CC  arch/x86/crypto/aesni-intel.mod.o
>   CC  arch/x86/crypto/crc32-pclmul.mod.o
>   CC  arch/x86/crypto/crc32c-intel.mod.o
> (..)
> 
> When reverting the entire pull with
> 
> git diff 84d69848c97faab0c25aa2667b273404d2e2a64a
> d4d24d2d0a7ea3b62efd7336bfc2344e29b36bc5 | patch -p1
> 
> everything is ok again.
> 
> My system is a Debian Stretch.
> gcc version 6.2.0 20161010 (Debian 6.2.0-6)
> 
> ..config is attached - in the case I have an unusual one from your
> perspective.
> 
> Regards,
> Oliver

Re: Kernel Freeze with American Megatrends BIOS

[Peter Wu]

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: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
> >>> device-specific. Steps to reproduce on the affected machines:
> >>>
> >>>  1. Load nouveau.
> >>>  2. Wait for it to runtime suspend.
> >>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> >>> reported.
> >>>
> >>
> >> I can confirm this. Same result on my machine.
> >>
> >> Here is a link to my ACPI tables:
> >> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz
> >>
> >> The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
> >>
> >>
> >> Method (PGON, 1, Serialized)
> >> {
> >> /* ... */
> >>
> >> GPPR (PION, One)
> >> If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
> >> Windows 2009 only works! */
> >> {
> > [..]
> >> }
> >> Else
> >> {
> >> LKEN (PION)
> >> }
> >>
> >> /* ... */
> >> 
> >> Return (Zero)
> >> }
> >>
> >>
> >>
> >> If not set to Windows 2009, then this is triggered:
> >>
> >>
> >> Method (LKEN, 1, NotSerialized)
> >> {
> > [..]
> >> }
> > 
> > Yep, this is the same code. I stripped out irrelevant parts from the
> > previous mail for brevity.
> > 
> >> Is it possible to override the specific ACPI table functions (SSDT) in the 
> >> DSDT?
> >> This way I could try to debug to find some more information...
> > 
> > See Documentation/acpi/initrd_table_override.txt and note that it is
> > important that the tables are really located at /kernel/firmware/acpi/
> > in your initrd (which must be the first, even before any possible
> > microcode updates).
> > 
> > What are you trying to do? For ACPI method tracing, see
> > Documentation/acpi/method-tracing.txt
> > 
> 
> Oh, you're right.
> 
> Thanks. Right now I am overriding the DSDT, but I am not able to override
> the SSDT, because I have to fix and compile all the SSDT files. There
> are too many compile errors... Wanted to find the exact line which
> is responsible for the hickup.

Have you disassembled with externs included? That is,

iasl -e *.dat -d ssdtX.dat

If you are sure that the remaining errors are harmless, you can use the
'-f' option to ignore errors. You can also use the `-ve` option to
suppress warnings and remarks so you can focus on the errors.

If you look at my notes.txt, you will see that _OFF always executes the
same code. PGON differs. When the problem occurs, "Q0L0" somehow always
reads back as non-zero and LNKS < 7.

> >>> Yes I suspect there is an ACPI and/ or PCI problem, possibly
> >>> device-specific. Steps to reproduce on the affected machines:
> >>>
> >>>  1. Load nouveau.
> >>>  2. Wait for it to runtime suspend.
> >>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> >>> reported.
> 
> I noticed following:
> 
> 1. Blacklist nouveau
> 2. Boot to GDM login manager (Wayland)
> 3. Switch to TTY with CTRL+ALT+FN2
> 4. Load bbswitch
> 5. Switch off GPU
> 6. run lspci -> no freeze
> 7. Switch to GDM
> 8. Login to a Wayland session (X11 won't work)
> 9. run lspci in a GUI terminal -> system freezes

Is nouveau somehow loaded anyway? All those extra components (X11,
Wayland, etc.) are unnecessary to reproduce the core problem. It occurs
whenever the device is being resumed (either via DSM/_PS0 or via power
resource PG00._ON).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

Re: Kernel Freeze with American Megatrends BIOS

[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: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
> > device-specific. Steps to reproduce on the affected machines:
> > 
> >  1. Load nouveau.
> >  2. Wait for it to runtime suspend.
> >  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> > reported.
> > 
> 
> I can confirm this. Same result on my machine.
> 
> Here is a link to my ACPI tables:
> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz
> 
> The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
> 
> 
> Method (PGON, 1, Serialized)
> {
> /* ... */
> 
> GPPR (PION, One)
> If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
> Windows 2009 only works! */
> {
[..]
> }
> Else
> {
> LKEN (PION)
> }
> 
> /* ... */
> 
> Return (Zero)
> }
> 
> 
> 
> If not set to Windows 2009, then this is triggered:
> 
> 
> Method (LKEN, 1, NotSerialized)
> {
[..]
> }

Yep, this is the same code. I stripped out irrelevant parts from the
previous mail for brevity.

> Is it possible to override the specific ACPI table functions (SSDT) in the 
> DSDT?
> This way I could try to debug to find some more information...

See Documentation/acpi/initrd_table_override.txt and note that it is
important that the tables are really located at /kernel/firmware/acpi/
in your initrd (which must be the first, even before any possible
microcode updates).

What are you trying to do? For ACPI method tracing, see
Documentation/acpi/method-tracing.txt
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

Re: Kernel Freeze with American Megatrends BIOS

[Peter Wu]

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
device-specific. Steps to reproduce on the affected machines:

 1. Load nouveau.
 2. Wait for it to runtime suspend.
 2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
 3. lspci never returns, few moments later an AML_INFINITE_LOOP is
reported.

If you use the external bbswitch module, the effect is the same. I have
been trying to debug this for some time on nouveau with no luck. The
PCI/PM D3cold patches from Mika makes no difference.

Runtime resume via nouveau triggers some ACPI methods (I'll assume the
Windows 8-style PR method and take the Clevo P651 as example):

\_SB.PCI0.PEG0.PG00._ON () ->
\_SB.PCI0.PGON (0)

Then:

Method (PGON, 1, Serialized) {
PION = Arg0 // note: 0 for PG00
// ...
If ((OSYS != 0x07DF)) { /* Not Windows 2015 (Windows 10), see below */ }
Else {
LKEN (PION)
}
// this is the infinite loop: it tries to bring the PCIe link to
// full speed, but fails to do so.
While ((\_SB.PCI0.PEG0.LNKS < 0x07)) {
Local0 = 0x20
While (Local0) {
If ((\_SB.PCI0.PEG0.LNKS < 0x07)) {
Stall (0x64)
Local0--
} Else { Break }
}
If ((Local0 == Zero)) {
\_SB.PCI0.PEG0.RTLK = One
Stall (0x64)
}
}
// ...
}

Without any workaround, this piece of code is invoked:

Method (LKEN, 1, NotSerialized) {
Local3 = (CPEX & 0x0F)  // CPEX at 0x5ff9be7f and has value 000506e3
If ((Local3 == Zero)) {
/* Similar to below, but with Q0L0 -> P0L0 (register 0xBC bit 6) */
} ElseIf ((Local3 != Zero)) {
If ((Arg0 == Zero)) {
/* Enter L0 Activate state.
 * (LKDS tries to enter L2, deep-energy-saving state.) */
Q0L0 = One  // register 0x249 bit 0; \_SB.PCI0.OPG0.Q0L0 
00:01.0
Sleep (0x10)
Local0 = Zero
While (Q0L0) {
If ((Local0 > 0x04)) { Break }
Sleep (0x10)
Local0++
}
} else { /* other cases, but we are only interested in PGON(0) */ }
}
}

The acpi_osi="!Windows 2015" workaround will invoke this instead:

If ((OSYS != 0x07DF)) {
If ((PION == Zero)) {
P0AP = Zero  /* PGOF writes 3 */
P0RM = Zero  /* PGOF writes 1 */
}
If ((PBGE != Zero)) { /* Observed to be false (PBGE == 0) */
If (SBDL (PION)) {
PUAB (PION)
CBDL = GUBC (PION)
MBDL = GMXB (PION)
If ((CBDL > MBDL)) {
CBDL = MBDL /* \_SB_.PCI0.MBDL */
}
PDUB (PION, CBDL)
}
}
If ((PION == Zero)) {
P0LD = Zero /* Link Disable = 0, PGOF sets 1 instead. */
P0TR = One  /* Train? (PGOF does not set this). */
TCNT = Zero
While ((TCNT < LDLY)) { /* LDLY = 300 */
If ((P0VC == Zero)) {
/* VC Negotiation Pending 0 means VC negotation is 
complete. */
Break
}
Sleep (0x10)
TCNT += 0x10 /* At most 19 iterations, sleeping for 304ms. */
}
}
}

The comments above are my own interpretation based on the acpidumps I
extracted from the machine. These notes and ACPI tables can be found at
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
https://github.com/Lekensteyn/acpi-stuff/tree/master/dsl/Clevo_P651RA

Other affected devices have similar code, differences are small:
 - No check for LNKS (avoids the infinite loop, but device is still off)
 - Instead of a check for != "Windows 2015", they check for == "Windows
   2009" or even for == "Windows 2009" || "Windows 2013" (Dell Inspiron
   7559).

The tested kernels (with bbswitch or nouveau) were Linux 4.4.0, 4.6,
4.7 (nouveau + PCI/PM + nouveau PR patches). The PCIe device is
something from the GTX 9xxM family in all cases.

I have a bunch of PCI config dumps from Windows and Linux, but there is
nothing extraordinary. Also did an ACPI trace via a Checked/Debug build
of Windows, but it just confirms that the ACPI method we use for the
Nvidia device is the correct one.

Let me know if you need more information, I would be glad to provide.

Kind regards,
Peter

> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> > Hi,
> > 
> > hope somebody can help me fix this kernel problem which affects the 
> >

Re: Kernel Freeze with American Megatrends BIOS

[Peter Wu]

On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote:
> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
>  wrote:
> > I configured bbswitch to not set any states automatically...
> > So it's possible to obtain and verify the GPU power state.
> >
> > However I removed the bbswitch module and booted with nouveau.
> >
> > Kernel 4.7.2: nouveau switches the discrete GPU off.
> >   I can't trigger the freeze, because bbswitch is missing.
> >   I'll work with the system and see if it will freeze.
> >
> > Kernel 4.8-rc4: nouveau does not care about the power state and
> > the discrete GPU is never switched off. I will notice
> > this, because the second cooling FAN will stop...
> > Same log messages as send before.
> 
> That's surprising. I believe there's an issue with the new logic when
> there's an HDMI audio subdevice. However that only appears if there's
> a cable plugged in, at least in the systems Peter tested. You should
> be able to see whether it's there or not with 'lspci'.

I doubt that the audio device is responsible here, that should only show
up after following very specific steps (runtime suspend/resume (PCI or
ACPI magic), remove PCI device, rescan bus).

> You can check for sure by looking in the vgaswitcheroo state. It
> should say DynOff when it's powered off.
> 
> Either way, I think using bbswitch + nouveau isn't supported by
> anyone, so if you want to use it that way, you're on your own. (You
> may want to load nouveau with runpm=0 so that nouveau doesn't try to
> manage the GPU suspend 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

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

[Peter Wu]

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 definition was inspired by the block/stat.txt documentation.

By the way, the ABI/README document is ambiguous on the meaning of
"Date", is it the creation date of the documentation entry or the
creation of the filesystem interface? I have chosen the latter here.

Kind regards,
Peter

 [1]: https://lkml.kernel.org/r/201012011729.18661.li...@egidy.de
 [2]: 
https://unix.stackexchange.com/questions/52215/determine-the-size-of-a-block-device#comment112867_52219
---
 Documentation/ABI/testing/sysfs-block | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-block 
b/Documentation/ABI/testing/sysfs-block
index 71d184d..b85a266 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -235,3 +235,20 @@ Description:
write_same_max_bytes is 0, write same is not supported
by the device.
 
+What:  /sys/block///start
+Date:  October 2002
+Contact:   linux-bl...@vger.kernel.org
+Kernel Version:2.5.43
+Description:
+   Starting position of the partition within the disk.
+   Measured in standard UNIX 512-byte sectors (not a
+   device-specific block size).
+
+What:  /sys/block///size
+Date:  October 2002
+Contact:   linux-bl...@vger.kernel.org
+Kernel Version:2.5.43
+Description:
+   Size of the partition in standard UNIX 512-byte sectors
+   (not a device-specific block size).
+
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 because napi_disable is called
> > before napi_enable.
> > 
> > Solve this by avoiding napi_enable in the resume during open function
> > (netif_running is true when open is called, IFF_UP is set after a
> > successful open; netif_running is false when close is called, but IFF_UP
> > is then still set).
> > 
> > While at it, remove WORK_ENABLE check from rtl8152_open (introduced with
> > the original change) because it cannot happen:
> > 
> >  - After this patch, runtime resume will not set it during rtl8152_open.
> >  - When link 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_enable from close to rtl8152_suspend
> 
> Acked-by: Hayes Wang 
> 
> Best Regards,
> Hayes

I found another problem with runtime PM. When a device is suspended via
autosuspend and a system suspend takes place, there is no network I/O
after resume. Triggering a renegotiation (ethtool -r eth1) brings back
network activity.

Can you have a look? I guess that reset_resume needs different
treatment, but don't know how to do it properly as suspend is not called
before system reset (because the device is apparently already in
suspended state).

I think that this new issue can be addressed in a different patch, this
patch solves a more severe lockup. Opinions?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

When an interface is brought up which was previously suspended (via
runtime PM), it would hang. This happens because napi_disable is called
before napi_enable.

Solve this by avoiding napi_enable in the resume during open function
(netif_running is true when open is called, IFF_UP is set after a
successful open; netif_running is false when close is called, but IFF_UP
is then still set).

While at it, remove WORK_ENABLE check from rtl8152_open (introduced with
the original change) because it cannot happen:

 - After this patch, runtime resume will not set it during rtl8152_open.
 - When link 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_enable from close to rtl8152_suspend

Tested with the scenario from
https://lkml.kernel.org/r/20151208111008.GA18728@al
(added debug prints to verify the suspend/resume moments)
---
 drivers/net/usb/r8152.c | 21 +++--
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d9427ca..2e32c41 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3067,17 +3067,6 @@ static int rtl8152_open(struct net_device *netdev)
 
mutex_lock(&tp->control);
 
-   /* The WORK_ENABLE may be set when autoresume occurs */
-   if (test_bit(WORK_ENABLE, &tp->flags)) {
-   clear_bit(WORK_ENABLE, &tp->flags);
-   usb_kill_urb(tp->intr_urb);
-   cancel_delayed_work_sync(&tp->schedule);
-
-   /* disable the tx/rx, if the workqueue has enabled them. */
-   if (netif_carrier_ok(netdev))
-   tp->rtl_ops.disable(tp);
-   }
-
tp->rtl_ops.up(tp);
 
rtl8152_set_speed(tp, AUTONEG_ENABLE,
@@ -3124,12 +3113,6 @@ static int rtl8152_close(struct net_device *netdev)
} else {
mutex_lock(&tp->control);
 
-   /* The autosuspend may have been enabled and wouldn't
-* be disable when autoresume occurs, because the
-* netif_running() would be false.
-*/
-   rtl_runtime_suspend_enable(tp, false);
-
tp->rtl_ops.down(tp);
 
mutex_unlock(&tp->control);
@@ -3512,7 +3495,7 @@ static int rtl8152_resume(struct usb_interface *intf)
netif_device_attach(tp->netdev);
}
 
-   if (netif_running(tp->netdev)) {
+   if (netif_running(tp->netdev) && tp->netdev->flags & IFF_UP) {
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
@@ -3532,6 +3515,8 @@ static int rtl8152_resume(struct usb_interface *intf)
}
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
} else if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
+   if (tp->netdev->flags & IFF_UP)
+   rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
}
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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->netdev)
> with this.

Simply replacing netif_running by IFF_UP does not work, it hangs during
close when the device is suspended. This patch is correct, but I have a
v2 patch that moves rtl_runtime_suspend_enable from close to suspend.

This is the evaluated scenario (run = netif_running, up = IFF_UP set):

# suspended before open
suspend (run=0, up=0)
open(run=1)
resume  (run=1, up=0)   <-- fixed by patch
(open ends)

# while up
suspend (run=1, up=1)
resume  (run=1, up=1)   <-- no issue, values match
suspend (run=1, up=1)

# close while suspended
close   (run=0, up=1)
resume  (run=0, up=1)   <-- fixed in patch v2
(close cont and ends)   <-- rtl_runtime_suspend_enable removed in v2
suspend (run=0, up=0)

# while down
resume  (run=0, up=0)
suspend (run=0, up=0)

# open while suspended, open fails
open(run=1)
resume  (run=1, up=0)   <-- fixed by patch
(open fails)
suspend (run=0, up=0)

> Excuse me. I have a question. Before the open() is finished, the
> netif_running() would be true, but the IFF_UP wouldn't be set. Is it
> right?

That is right, this happens behind the scenes:

# open
netif_running = true
open()
if open succeeded
set IFF_UP
else
netif_running = false

# close
netif_running = false
close()
clear IFF_UP
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

When an interface is brought up which was previously suspended (via
runtime PM), it would hang. This happens because napi_disable is called
before napi_enable.

Solve this by avoiding napi_disable before the device is fully up.

While at it, remove WORK_ENABLE check from rtl8152_open (introduced with
the original change) because it cannot happen:

 - After this patch, runtime resume will not set it during rtl8152_open.
 - When link 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 
---
 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..b8b083e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3067,17 +3067,6 @@ static int rtl8152_open(struct net_device *netdev)
 
mutex_lock(&tp->control);
 
-   /* The WORK_ENABLE may be set when autoresume occurs */
-   if (test_bit(WORK_ENABLE, &tp->flags)) {
-   clear_bit(WORK_ENABLE, &tp->flags);
-   usb_kill_urb(tp->intr_urb);
-   cancel_delayed_work_sync(&tp->schedule);
-
-   /* disable the tx/rx, if the workqueue has enabled them. */
-   if (netif_carrier_ok(netdev))
-   tp->rtl_ops.disable(tp);
-   }
-
tp->rtl_ops.up(tp);
 
rtl8152_set_speed(tp, AUTONEG_ENABLE,
@@ -3516,11 +3505,13 @@ static int rtl8152_resume(struct usb_interface *intf)
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
-   napi_disable(&tp->napi);
-   set_bit(WORK_ENABLE, &tp->flags);
-   if (netif_carrier_ok(tp->netdev))
-   rtl_start_rx(tp);
-   napi_enable(&tp->napi);
+   if (tp->netdev->flags & IFF_UP) {
+   napi_disable(&tp->napi);
+   set_bit(WORK_ENABLE, &tp->flags);
+   if (netif_carrier_ok(tp->netdev))
+   rtl_start_rx(tp);
+   napi_enable(&tp->napi);
+   }
} else {
tp->rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 if auto-pm 
> >> is disabled?
> >>
> >> I always disable usb auto-pm in below way.
> >>
> >> # echo on | tee /sys/bus/usb/devices/*/power/control
> >> # echo on > /sys/bus/pci/devices//power/control
> >>
> >> Thanks,
> >> Baolu
> > Hi Baolu,
> >
> > The deadlock does not seem to occur with auto-PM disabled, but that is a
> > workaround for the issue. The hang can always be reproduced under this
> > test:
> >
> >  - Start a QEMU VM, passing through the USB adapter
> 
> I would suggest you to start with bare metal.
> 
> When you pass through the host controller to a guest VM, you
> probably use IOMMU unit to let hardware access the memory
> directly, but things like pci configure space access, interrupt and
> IO port access still rely on QEMU. This introduces a lot of complexities.

It is a USB device, not a PCI device, so such issues do not apply here
I think.

I have found a possible reason for this lockup. The resume code may
execute napi_disable while napi_enable was not called before. This
autoresume thing happens in the open function which explains why all
other rtnl users are blocked.

Is this a sane analysis?

Kind regards,
Peter

> Thanks,
> Baolu
> 
> >  - This VM boots to a busybox shell with no other services running or
> >udev magic (to reduce interference).
> >  - Enable runtime PM for all devices by default (see script below)
> >  - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
> >adapter).
> >
> > # somewhere in /init after mounting filesystems
> > echo /sbin/hotplug > /proc/sys/kernel/hotplug
> > echo auto | tee  /sys/bus/pci/devices/*/power/control \
> > /sys/bus/usb/devices/*/power/control >/dev/null
> >
> > #!/bin/sh
> > # /sbin/hotplug
> > path="/sys/$DEVPATH/power/control"
> > [ -e "$path" ] || return
> > newval=auto
> > read status < "$path"
> > if [ "x$status" != "x$newval" ]; then
> > echo "$DEVPATH: $status -> $newval" >/dev/kmsg
> > echo $newval > "$path"
> > fi
> >
> > With "auto", the ip command hangs (a trace can be found on the bottom of
> > this mail). With "on", it does not.
> >
> > If I keep a loop spinning that invokes `ethtool eth1`, the command
> > returns immediately without issues (presumably because the device is not
> > suspended through runtime PM).
> >
> > Under some circumstances I get a lockdep warning (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 and try to claim tp->lock too.
> >
> > Maybe there are two different lockup cases here, I'll keep testing.
> >
> > Kind regards,
> > Peter
> >
> >> On 12/05/2015 06:59 PM, Peter Wu wrote:
> >>> Hi,
> >>>
> >>> I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> >>> 0bda:8153), but when I did last night, it resulted in a lockup of
> >>> processes doing networking ("ip link", "ping", "ethtool", ...).
> >>>
> >>> A (few) minute(s) before that event, I noticed that there was no network
> >>> connectivity (ping hung) which was somehow solved by invoking "ethtool
> >>> eth1" (triggering runtime pm wakeup?). This same trick did not work at
> >>> the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> >>> and interrupt (^C) did not work at all.
> >>>
> >>> Since that did not work, I pulled the USB adapter and re-inserted it,
> >>> hoping it would reset things. That did not work at all, there was a
> >>> "usb disconnect" message, but no further driver messages.
> >>>
> >>> Fast forward an hour, and it has become a disaster. I have terminated
> >>> and killed many programs via SysRq but am still unable to get a stable
> >>

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

[Peter Wu]

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 if auto-pm is 
> disabled?
> 
> I always disable usb auto-pm in below way.
> 
> # echo on | tee /sys/bus/usb/devices/*/power/control
> # echo on > /sys/bus/pci/devices//power/control
> 
> Thanks,
> Baolu

Hi Baolu,

The deadlock does not seem to occur with auto-PM disabled, but that is a
workaround for the issue. The hang can always be reproduced under this
test:

 - Start a QEMU VM, passing through the USB adapter
 - This VM boots to a busybox shell with no other services running or
   udev magic (to reduce interference).
 - Enable runtime PM for all devices by default (see script below)
 - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
   adapter).

# somewhere in /init after mounting filesystems
echo /sbin/hotplug > /proc/sys/kernel/hotplug
echo auto | tee  /sys/bus/pci/devices/*/power/control \
/sys/bus/usb/devices/*/power/control >/dev/null

#!/bin/sh
# /sbin/hotplug
path="/sys/$DEVPATH/power/control"
[ -e "$path" ] || return
newval=auto
read status < "$path"
if [ "x$status" != "x$newval" ]; then
echo "$DEVPATH: $status -> $newval" >/dev/kmsg
echo $newval > "$path"
fi

With "auto", the ip command hangs (a trace can be found on the bottom of
this mail). With "on", it does not.

If I keep a loop spinning that invokes `ethtool eth1`, the command
returns immediately without issues (presumably because the device is not
suspended through runtime PM).

Under some circumstances I get a lockdep warning (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 and try to claim tp->lock too.

Maybe there are two different lockup cases here, I'll keep testing.

Kind regards,
Peter

> On 12/05/2015 06:59 PM, Peter Wu wrote:
> > Hi,
> >
> > I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> > 0bda:8153), but when I did last night, it resulted in a lockup of
> > processes doing networking ("ip link", "ping", "ethtool", ...).
> >
> > A (few) minute(s) before that event, I noticed that there was no network
> > connectivity (ping hung) which was somehow solved by invoking "ethtool
> > eth1" (triggering runtime pm wakeup?). This same trick did not work at
> > the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> > and interrupt (^C) did not work at all.
> >
> > Since that did not work, I pulled the USB adapter and re-inserted it,
> > hoping it would reset things. That did not work at all, there was a
> > "usb disconnect" message, but no further driver messages.
> >
> > Fast forward an hour, and it has become a disaster. I have terminated
> > and killed many programs via SysRq but am still unable to get a stable
> > system that does not hang on network I/O. Even the suspend process
> > fails so in the end I attempted to shutdown the system. After half an
> > hour after getting the poweroff message, I issued SysRq + B to reboot
> > (since SysRq + O did not shut down either).
> >
> > Attached are logs with various various backtraces from SysRq and failed
> > suspend. Let me know if you need more information!
> >
> > By the way, often I have to rmmod xhci and re-insert it, otherwise
> > plugging it in does not result in a detection. A USB 2.0 port does not
> > have this problem (runtime PM is enabled for 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)
> 

-- 

lockdep splat from the bare machine:

==
[ INFO: possible circular locking dependency detected ]
4.3.0-custom #1 Tainted: G   O   
---
kworker/0:1/38 is trying to acquire lock:
 (&tp->control){+.+.+.}, at: [] rtl8152_resume+0x24/0x130 
[r8152]

but task is already holding lock:
 ((&(&tp->schedule)->work)){+.+.+.}, at: [] 
process_one_work+0x15c/0x660

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 ((&(&tp->schedule)->work)){+.+.+.}:

[] lock_acquire+0xc3/0x1d0
   [] flush_wo

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

[Peter Wu]

Free skb for received frames with a wrong checksum. This can happen
pretty rapidly, exhausting all memory.

This fixes a memleak (detected with kmemleak). Originally found while
using monitor mode, but it also appears during managed mode (once the
link is up).

Cc: sta...@vger.kernel.org
Signed-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/realtek/rtlwifi/usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 2721cf8..aac1ed3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -531,6 +531,8 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw 
*hw,
ieee80211_rx(hw, skb);
else
dev_kfree_skb_any(skb);
+   } else {
+   dev_kfree_skb_any(skb);
}
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 (observable via the Available column in `free -m`).
> >
> >Test scenario:
> >
> > ip link set down wlan1
> > iw wlan1 set type monitor
> > ip link set up wlan1
> > 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 introduction of this driver in v2.6.x,
> >using kmemleak I was about to figure out the source. There is also a
> >_rtl_usb_rx_process_agg that has similarly looking code, but that one is
> >unaffected. The pci code already frees the skb and is unaffected too.
> >
> >Tested with kernel v4.3, this patch is simply rebased on v4.4-rc3 (due
> >to changed paths).
> >
> >Kind regards,
> >Peter
> >---
> >  drivers/net/wireless/realtek/rtlwifi/usb.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> >diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
> >b/drivers/net/wireless/realtek/rtlwifi/usb.c
> >index 2721cf8..aac1ed3 100644
> >--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
> >+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
> >@@ -531,6 +531,8 @@ static void _rtl_usb_rx_process_noagg(struct 
> >ieee80211_hw *hw,
> > ieee80211_rx(hw, skb);
> > else
> > dev_kfree_skb_any(skb);
> >+} else {
> >+dev_kfree_skb_any(skb);
> > }
> >  }
> >
> >
> 
> Thanks for finding and fixing this memory leak.
> 
> The patch is OK, but the commit message and subject are not. I do not like
> the use of the word "gigantic" in the subject. A better subject would be:
> "rtlwifi: Fix memory leak for USB device while in monitor mode".
> 
> The commit message should say that a memory leak was observed, and found
> with kmemleak. If you were simply reportimg the bug, then the steps needed
> to reproduce it would be important, but as you have a fix, those steps are
> extraneous. You should also include a "Cc: Stable  line. When the patch is picked up for stable kernels, it will be necessary
> to rebase the patch to compensate for the directory change.

I have done some additional testing using QEMU and USB passthrough and
can report that the leak is not limited to monitor mode. The commit
message is adjusted for that. This issue is pretty bad, I previously hit
5GB within an hour with low traffic, this VM with 256M RAM panics after
5 minutes in managed mode. (Remote denial of service, heh.)

Originally I had the Cc: stable line added, but the SubmittingPatches
document seems to discourage that for networking. Added it again.

Here is the updated patch, hopefully addressing your concerns. Feel free
to modify it as you find appropriate.

Peter
--
>From a2c5fec1789bef48671d643ea7ecd0244d1e0246 Mon Sep 17 00:00:00 2001
From: Peter Wu 
Date: Sun, 6 Dec 2015 17:59:41 +0100
Subject: [PATCH] rtlwifi: fix memory leak for USB device

Free skb for received frames with a wrong checksum. This can happen
pretty rapidly, exhausting all memory.

This fixes a memleak (detected with kmemleak). Originally found while
using monitor mode, but it also appears during managed mode (once the
link is up).

Cc: sta...@vger.kernel.org
Signed-off-by: Peter Wu 
---
 drivers/net/wireless/realtek/rtlwifi/usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 2721cf8..aac1ed3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -531,6 +531,8 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw 
*hw,
ieee80211_rx(hw, skb);
else
dev_kfree_skb_any(skb);
+   } else {
+   dev_kfree_skb_any(skb);
}
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] rtlwifi: fix gigantic memleak in rtl_usb

[Peter Wu]

Free skb for received frames with a wrong checksum.

While using the rtl8192cu driver in monitor mode, somehow 5G of memory
was permanently lost (observable via the Available column in `free -m`).

Test scenario:

ip link set down wlan1
iw wlan1 set type monitor
ip link set up wlan1
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 introduction of this driver in v2.6.x,
using kmemleak I was about to figure out the source. There is also a
_rtl_usb_rx_process_agg that has similarly looking code, but that one is
unaffected. The pci code already frees the skb and is unaffected too.

Tested with kernel v4.3, this patch is simply rebased on v4.4-rc3 (due
to changed paths).

Kind regards,
Peter
---
 drivers/net/wireless/realtek/rtlwifi/usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 2721cf8..aac1ed3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -531,6 +531,8 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw 
*hw,
ieee80211_rx(hw, skb);
else
dev_kfree_skb_any(skb);
+   } else {
+   dev_kfree_skb_any(skb);
}
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

(4.3.0) r8152: deadlock related to runtime suspend?

[Peter Wu]

Hi,

I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
0bda:8153), but when I did last night, it resulted in a lockup of
processes doing networking ("ip link", "ping", "ethtool", ...).

A (few) minute(s) before that event, I noticed that there was no network
connectivity (ping hung) which was somehow solved by invoking "ethtool
eth1" (triggering runtime pm wakeup?). This same trick did not work at
the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
and interrupt (^C) did not work at all.

Since that did not work, I pulled the USB adapter and re-inserted it,
hoping it would reset things. That did not work at all, there was a
"usb disconnect" message, but no further driver messages.

Fast forward an hour, and it has become a disaster. I have terminated
and killed many programs via SysRq but am still unable to get a stable
system that does not hang on network I/O. Even the suspend process
fails so in the end I attempted to shutdown the system. After half an
hour after getting the poweroff message, I issued SysRq + B to reboot
(since SysRq + O did not shut down either).

Attached are logs with various various backtraces from SysRq and failed
suspend. Let me know if you need more information!

By the way, often I have to rmmod xhci and re-insert it, otherwise
plugging it in does not result in a detection. A USB 2.0 port does not
have this problem (runtime PM is enabled for 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 NetworkManager[441]:   Could not get scan request 
result: Timeout was reached
Dec 05 00:35:45 al NetworkManager[441]:   Could not get scan request 
result: Timeout was reached
Dec 05 00:36:13 al kernel: INFO: task wpa_supplicant:573 blocked for more than 
120 seconds.
Dec 05 00:36:13 al kernel:   Tainted: G   O4.3.0-1-ARCH #1
Dec 05 00:36:13 al kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
Dec 05 00:36:13 al kernel: wpa_supplicant  D 88023bc956c0 0   573  
1 0x
Dec 05 00:36:13 al kernel:  8800aca2fa48 0086 880232600c80 
88022d101900
Dec 05 00:36:13 al kernel:  8800aca3 818b4504 88022d101900 

Dec 05 00:36:13 al kernel:  818b4508 8800aca2fa60 8157a09a 
818b4500
Dec 05 00:36:13 al kernel: Call Trace:
Dec 05 00:36:13 al kernel:  [] schedule+0x3a/0x90
Dec 05 00:36:13 al kernel:  [] 
schedule_preempt_disabled+0x15/0x20
Dec 05 00:36:13 al kernel:  [] 
__mutex_lock_slowpath+0xce/0x140
Dec 05 00:36:13 al kernel:  [] mutex_lock+0x17/0x30
Dec 05 00:36:13 al kernel:  [] rtnl_lock+0x15/0x20
Dec 05 00:36:13 al kernel:  [] nl80211_pre_doit+0xeb/0x180 
[cfg80211]
Dec 05 00:36:13 al kernel:  [] genl_family_rcv_msg+0x1c8/0x3c0
Dec 05 00:36:13 al kernel:  [] ? 
genl_family_rcv_msg+0x3c0/0x3c0
Dec 05 00:36:13 al kernel:  [] genl_rcv_msg+0x76/0xb0
Dec 05 00:36:13 al kernel:  [] netlink_rcv_skb+0xa4/0xc0
Dec 05 00:36:13 al kernel:  [] genl_rcv+0x28/0x40
Dec 05 00:36:13 al kernel:  [] netlink_unicast+0x11a/0x1a0
Dec 05 00:36:13 al kernel:  [] netlink_sendmsg+0x4f8/0x610
Dec 05 00:36:13 al kernel:  [] sock_sendmsg+0x17/0x30
Dec 05 00:36:13 al kernel:  [] ___sys_sendmsg+0x295/0x2b0
Dec 05 00:36:13 al kernel:  [] ? 
should_numa_migrate_memory+0x54/0x130
Dec 05 00:36:13 al kernel:  [] ? handle_mm_fault+0xb38/0x18a0
Dec 05 00:36:13 al kernel:  [] __sys_sendmsg+0x51/0x90
Dec 05 00:36:13 al kernel:  [] SyS_sendmsg+0x12/0x20
Dec 05 00:36:13 al kernel:  [] 
entry_SYSCALL_64_fastpath+0x12/0x71
Dec 05 00:36:13 al kernel: INFO: task Qt bearer threa:8292 blocked for more 
than 120 seconds.
Dec 05 00:36:13 al kernel:   Tainted: G   O4.3.0-1-ARCH #1
Dec 05 00:36:13 al kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
Dec 05 00:36:13 al kernel: Qt bearer threa D 88023bd156c0 0  8292   
8222 0x
Dec 05 00:36:13 al kernel:  8800ac9bfc88 0086 880232601900 
880214323200
Dec 05 00:36:13 al kernel:  8800ac9c 818b4504 880214323200 

Dec 05 00:36:13 al kernel:  818b4508 8800ac9bfca0 8157a09a 
818b4500
Dec 05 00:36:13 al kernel: Call Trace:
Dec 05 00:36:13 al kernel:  [] schedule+0x3a/0x90
Dec 05 00:36:13 al kernel:  [] 
schedule_preempt_disabled+0x15/0x20
Dec 05 00:36:13 al kernel:  [] 
__mutex_lock_slowpath+0xce/0x140
Dec 05 00:36:13 al kernel:  [] mutex_lock+0x17/0x30
Dec 05 00:36:13 al kernel:  [] rtnetlink_rcv+0x19/0x30
Dec 05 00:36:13 al kernel:  [] netlink_unicast+0x11a/0x1a0
Dec 05 00:36:13 al kernel:  [] netlink_sendmsg+0x4f8/0x610
Dec 05 00:36:13 al kernel: 

[PATCH] Documentation: Remove output class document

[Peter Wu]

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 deletions(-)
 delete mode 100644 Documentation/video-output.txt

diff --git a/Documentation/video-output.txt b/Documentation/video-output.txt
deleted file mode 100644
index e517011..000
--- a/Documentation/video-output.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-
-   Video Output Switcher Control
-   ~
-   2006 luming...@intel.com
-
-The output sysfs class driver provides an abstract video output layer that
-can be used to hook platform specific methods to enable/disable video output
-device through common sysfs interface. For example, on my IBM ThinkPad T42
-laptop, The ACPI video driver registered its output devices and read/write
-method for 'state' with output sysfs class. The user interface under sysfs is:
-
-linux:/sys/class/video_output # tree .
-.
-|-- CRT0
-|   |-- device -> ../../../devices/pci:00/:00:01.0
-|   |-- state
-|   |-- subsystem -> ../../../class/video_output
-|   `-- uevent
-|-- DVI0
-|   |-- device -> ../../../devices/pci:00/:00:01.0
-|   |-- state
-|   |-- subsystem -> ../../../class/video_output
-|   `-- uevent
-|-- LCD0
-|   |-- device -> ../../../devices/pci:00/:00:01.0
-|   |-- state
-|   |-- subsystem -> ../../../class/video_output
-|   `-- uevent
-`-- TV0
-   |-- device -> ../../../devices/pci:00/:00:01.0
-   |-- state
-   |-- subsystem -> ../../../class/video_output
-   `-- uevent
-
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

On Thursday 08 January 2015 14:37:12 Benjamin Tissoires wrote:
> If a disconnect occurs while getting the actual name of the device
> (which can take several HID transactions), the name of the device will
> be the hid name, provided by the Unifying Receiver.
> This means that in some cases, the user space will see a different
> name that what it usually sees when there is no disconnect.
> 
> We should store the name of the device in the struct hidpp. That way,
> if a disconnect occurs while we are accessing the name,
> hidpp_connect_event() can fail, and the 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: Benjamin Tissoires 
> ---
> 
> Hi,
> 
> sorry for the delay.
> Peter, I amended the patch to add a comment in the declaration of .name.
> If this is not what you had in mind (or if it is not sufficient), please tell
> me. I still kept your tested and S-o-b lines, but feel free to retract 
> yourself :)
> 
> Cheers,
> Benjamin

Maybe it would be better to explain that the pointer is never NULL
because the memory is owned by the upper device (struct hid_device?),
then it is obvious that the memory is not allocated by this driver
itself.

With or without this elaboration the patch and comment is still correct,
so there is no reason to retract the R-b and T-b though.

Kind regards,
Peter

>  drivers/hid/hid-logitech-hidpp.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index c8af315..e77658c 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -89,6 +89,7 @@ struct hidpp_device {
>   struct hid_device *hid_dev;
>   struct mutex send_mutex;
>   void *send_receive_buf;
> + char *name; /* will never be NULL and should not be freed */
>   wait_queue_head_t wait;
>   bool answer_available;
>   u8 protocol_major;
> @@ -1087,6 +1088,7 @@ static void hidpp_input_close(struct input_dev *dev)
>  static struct input_dev *hidpp_allocate_input(struct hid_device *hdev)
>  {
>   struct input_dev *input_dev = devm_input_allocate_device(&hdev->dev);
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
>  
>   if (!input_dev)
>   return NULL;
> @@ -1095,7 +1097,7 @@ static struct input_dev *hidpp_allocate_input(struct 
> hid_device *hdev)
>   input_dev->open = hidpp_input_open;
>   input_dev->close = hidpp_input_close;
>  
> - input_dev->name = hdev->name;
> + input_dev->name = hidpp->name;
>   input_dev->phys = hdev->phys;
>   input_dev->uniq = hdev->uniq;
>   input_dev->id.bustype = hdev->bus;
> @@ -1137,22 +1139,28 @@ static void hidpp_connect_event(struct hidpp_device 
> *hidpp)
>   hid_info(hdev, "HID++ %u.%u device connected.\n",
>hidpp->protocol_major, hidpp->protocol_minor);
>  
> + if (!hidpp->name || hidpp->name == hdev->name) {
> + name = hidpp_get_device_name(hidpp);
> + if (!name) {
> + hid_err(hdev,
> + "unable to retrieve the name of the device");
> + return;
> + }
> +
> + devm_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s", name);
> + kfree(name);
> + if (!devm_name)
> + return;
> +
> + hidpp->name = devm_name;
> + }
> +
>   input = hidpp_allocate_input(hdev);
>   if (!input) {
>   hid_err(hdev, "cannot allocate new input device: %d\n", ret);
>   return;
>   }
>  
> - name = hidpp_get_device_name(hidpp);
> - if (!name) {
> - hid_err(hdev, "unable to retrieve the name of the device");
> - } else {
> - devm_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s", name);
> - if (devm_name)
> - input->name = devm_name;
> - kfree(name);
> - }
> -
>   hidpp_populate_input(hidpp, input, false);
>  
>   ret = input_register_device(input);
> @@ -1175,6 +1183,7 @@ static int hidpp_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   return -ENOMEM;
>  
>   hidpp->hid_dev = hdev;
> + hidpp->name = hdev->name;
>   hid_set_drvdata(hdev, hidpp);
>  
>   hidpp->quirks = id->driver_data;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 an
> > error. Caught by... well, a bug in the QEMU emulation of this receiver.
> >
> > Renamed fap to rap for HID++ 1.0 errors because it is more logical,
> > it has no functional difference.
> >
> > Signed-off-by: Peter Wu 
> > ---
> 
> I'd like to have Nestor's opinion on this. I did not manage to find on
> the documentation that HID++ 2.0 Long report error code is 0xff, so
> introducing this change without Logitech's blessing would be
> unfortunate.
> I understand this will fix your qemu problem, but I am not entirely
> sure if we do not have to check on 0xff and 0x8f in both short and
> long responses.
> 
> Cheers,
> Benjamin

Hi Benjamin,

The Logitech Unifying extension for Chrome[1] is documented quite well
and contains details which were not public before (including names and
descriptions for all registers and subIDs!).

In lib/devices/HidppFap.js you can find this logic for handling HID++
2.0 messages:

if ((reqView.getUint8(1) == rspView.getUint8(1)) //  device index
&& (reqView.getUint8(2) == rspView.getUint8(2)) // feature index
&& (reqView.getUint8(3) == rspView.getUint8(3))) // function/event ID + 
software ID
{
result.matchResult = devices.MATCH_RESULT.SUCCESS;
} else if ((reqView.getUint8(1) == rspView.getUint8(1)) //  device index
&& (0xFF == rspView.getUint8(2)) // Hid++ 2.0 error
&& (reqView.getUint8(2) == rspView.getUint8(3)) // feature index
&& (reqView.getUint8(3) == rspView.getUint8(4))) // function/event ID + 
software ID
{
result.errCode = rspView.getUint8(5); // FAP_ERROR
result.matchResult = devices.MATCH_RESULT.ERROR;
}

Looks like a sufficient proof that 0xFF is the correct number to detect
HID++ 2.0 errors right?

In HID++ 1.0 devices ("rap"), 0xFF is named as "SYNC" (with no further
comments), so this will probably not trigger false positives either.

Kind regards,
Peter

 [1]: 
https://chrome.google.com/webstore/detail/logitech-unifying-for-chr/agpmgihmmmfkbhckmciedmhincdggomo

> >  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-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -105,6 +105,7 @@ struct hidpp_device {
> >  };
> >
> >
> > +/* HID++ 1.0 error codes */
> >  #define HIDPP_ERROR0x8f
> >  #define HIDPP_ERROR_SUCCESS0x00
> >  #define HIDPP_ERROR_INVALID_SUBID  0x01
> > @@ -119,6 +120,8 @@ struct hidpp_device {
> >  #define HIDPP_ERROR_REQUEST_UNAVAILABLE0x0a
> >  #define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
> >  #define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
> > +/* HID++ 2.0 error codes */
> > +#define HIDPP20_ERROR  0xff
> >
> >  static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
> >
> > @@ -192,9 +195,16 @@ static int hidpp_send_message_sync(struct hidpp_device 
> > *hidpp,
> > }
> >
> > if (response->report_id == REPORT_ID_HIDPP_SHORT &&
> > -   response->fap.feature_index == HIDPP_ERROR) {
> > +   response->rap.sub_id == HIDPP_ERROR) {
> > +   ret = response->rap.params[1];
> > +   dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
> > +   goto exit;
> > +   }
> > +
> > +   if (response->report_id == REPORT_ID_HIDPP_LONG &&
> > +   response->fap.feature_index == HIDPP20_ERROR) {
> > ret = response->fap.params[1];
> > -   dbg_hid("__hidpp_send_report got hidpp error %02X\n", ret);
> > +   dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
> > goto exit;
> > }
> >
> > @@ -271,7 +281,8 @@ static inline bool hidpp_match_answer(struct 
> > hidpp_report *question,
> >  static inline bool hidpp_match_error(struct hidpp_report *question,
> > struct hidpp_report *answer)
> >  {
> > -   return (answer->fap.feature_index == HIDPP_ERROR) &&am

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

[Peter Wu]

Sorry for the rapid mail, I forgot to mention something.

wtp_connect won't work on non-HID++ devices. What about moving it down,
between the generic routines (reading protocol and name) and
hidpp_allocate_input? Then the connected parameter can also be dropped.

Kind regards,
Peter

On Wednesday 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.
> > 
> > Signed-off-by: Benjamin Tissoires 
> > ---
> >  drivers/hid/hid-logitech-hidpp.c | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > b/drivers/hid/hid-logitech-hidpp.c
> > index d008d71..c0fb5fe 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -914,24 +914,24 @@ static int wtp_allocate(struct hid_device *hdev, 
> > const struct hid_device_id *id)
> > return 0;
> >  };
> >  
> > -static void wtp_connect(struct hid_device *hdev, bool connected)
> > +static int wtp_connect(struct hid_device *hdev, bool connected)
> >  {
> > struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > struct wtp_data *wd = hidpp->private_data;
> > int ret;
> >  
> > if (!connected)
> > -   return;
> > +   return 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 meaningful.)
> 
> Whether or not you change the return value is up to you. This patch is
> Reviewed-by: Peter Wu 
> 
> Kind regards,
> Peter
> 
> > if (!wd->x_size) {
> > ret = wtp_get_config(hidpp);
> > if (ret) {
> > hid_err(hdev, "Can not get wtp config: %d\n", ret);
> > -   return;
> > +   return ret;
> > }
> > }
> >  
> > -   hidpp_touchpad_set_raw_report_state(hidpp, wd->mt_feature_index,
> > +   return hidpp_touchpad_set_raw_report_state(hidpp, wd->mt_feature_index,
> > true, true);
> >  }
> >  
> > @@ -1115,8 +1115,11 @@ static void hidpp_connect_event(struct hidpp_device 
> > *hidpp)
> > struct input_dev *input;
> > char *name, *devm_name;
> >  
> > -   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > -   wtp_connect(hdev, connected);
> > +   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP) {
> > +   ret = wtp_connect(hdev, connected);
> > +   if (ret)
> > +   return;
> > +   }
> >  
> > if (!connected || hidpp->delayed_input)
> > return;
> > 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 now, the patch "HID: logitech-hidpp: detect HID++ 2.0 errors
> too" is waiting for Logitech's approval, and the 2 of this series need
> review.
> 
> Peter, please tell me if I missed one patch.
 
Nice, it would be even better if a bundle could be bookmarked, or if a
group could set review flags in this bundle :-)

There are no missing patches from my side. All changes (based on
jikos/hid, branch for-next) are at
https://git.lekensteyn.nl/peter/linux/log/?h=logitech-hidpp
and are tested in QEMU with an emulated device and a real device (with
T400/T650/M525 paired).

I noticed that all devices would immediately get an input device (even
if they were off), except for the T650. This apparently happens because
the touchpad configuration cannot be retrieved or when the touchpad
cannot be put in raw reporting mode. I cannot think of something to
"fix" this though.
-- 
Kind regards,
Peter
https://lekensteyn.nl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

On Tuesday 16 December 2014 17:06:02 Benjamin Tissoires wrote:
> If a disconnect occurs while getting the actual name of the device
> (which can take several HID transactions), the name of the device will
> be the hid name, provided by the Unifying Receiver.
> This means that in some cases, the user space will see a different
> name that what it usually sees when there is no disconnect.
> 
> We should store the name of the device in the struct hidpp. That way,
> if a disconnect occurs while we are accessing the name,
> hidpp_connect_event() can fail, and the 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.
> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/hid/hid-logitech-hidpp.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index c0fb5fe..4bc8714 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -89,6 +89,7 @@ struct hidpp_device {
>   struct hid_device *hid_dev;
>   struct mutex send_mutex;
>   void *send_receive_buf;
> + char *name;
>   wait_queue_head_t wait;
>   bool answer_available;
>   u8 protocol_major;
> @@ -1087,6 +1088,7 @@ static void hidpp_input_close(struct input_dev *dev)
>  static struct input_dev *hidpp_allocate_input(struct hid_device *hdev)
>  {
>   struct input_dev *input_dev = devm_input_allocate_device(&hdev->dev);
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
>  
>   if (!input_dev)
>   return NULL;
> @@ -1095,7 +1097,7 @@ static struct input_dev *hidpp_allocate_input(struct 
> hid_device *hdev)
>   input_dev->open = hidpp_input_open;
>   input_dev->close = hidpp_input_close;
>  
> - input_dev->name = hdev->name;
> + input_dev->name = hidpp->name;
>   input_dev->phys = hdev->phys;
>   input_dev->uniq = hdev->uniq;
>   input_dev->id.bustype = hdev->bus;
> @@ -1137,22 +1139,28 @@ static void hidpp_connect_event(struct hidpp_device 
> *hidpp)
>   hid_info(hdev, "HID++ %u.%u device connected.\n",
>hidpp->protocol_major, hidpp->protocol_minor);
>  
> + if (!hidpp->name || hidpp->name == hdev->name) {

Hm, is it ever possible that hidpp->name is NULL? 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 device 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 
Tested-by: Peter Wu 

Kind regards,
Peter

> + name = hidpp_get_device_name(hidpp);
> + if (!name) {
> + hid_err(hdev,
> + "unable to retrieve the name of the device");
> + return;
> + }
> +
> + devm_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s", name);
> + kfree(name);
> + if (!devm_name)
> + return;
> +
> + hidpp->name = devm_name;
> + }
> +
>   input = hidpp_allocate_input(hdev);
>   if (!input) {
>   hid_err(hdev, "cannot allocate new input device: %d\n", ret);
>   return;
>   }
>  
> - name = hidpp_get_device_name(hidpp);
> - if (!name) {
> - hid_err(hdev, "unable to retrieve the name of the device");
> - } else {
> - devm_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s", name);
> - if (devm_name)
> - input->name = devm_name;
> - kfree(name);
> - }
> -
>   hidpp_populate_input(hidpp, input, false);
>  
>   ret = input_register_device(input);
> @@ -1175,6 +1183,7 @@ static int hidpp_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   return -ENOMEM;
>  
>   hidpp->hid_dev = hdev;
> + hidpp->name = hdev->name;
>   hid_set_drvdata(hdev, hidpp);
>  
>   hidpp->quirks = id->driver_data;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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.
> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/hid/hid-logitech-hidpp.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index d008d71..c0fb5fe 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -914,24 +914,24 @@ static int wtp_allocate(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   return 0;
>  };
>  
> -static void wtp_connect(struct hid_device *hdev, bool connected)
> +static int wtp_connect(struct hid_device *hdev, bool connected)
>  {
>   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
>   struct wtp_data *wd = hidpp->private_data;
>   int ret;
>  
>   if (!connected)
> - return;
> + return 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 meaningful.)

Whether or not you change the return value is up to you. This patch is
Reviewed-by: Peter Wu 

Kind regards,
Peter

>   if (!wd->x_size) {
>   ret = wtp_get_config(hidpp);
>   if (ret) {
>   hid_err(hdev, "Can not get wtp config: %d\n", ret);
> - return;
> + return ret;
>   }
>   }
>  
> - hidpp_touchpad_set_raw_report_state(hidpp, wd->mt_feature_index,
> + return hidpp_touchpad_set_raw_report_state(hidpp, wd->mt_feature_index,
>   true, true);
>  }
>  
> @@ -1115,8 +1115,11 @@ static void hidpp_connect_event(struct hidpp_device 
> *hidpp)
>   struct input_dev *input;
>   char *name, *devm_name;
>  
> - if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> - wtp_connect(hdev, connected);
> + if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP) {
> + ret = wtp_connect(hdev, connected);
> + if (ret)
> + return;
> + }
>  
>   if (!connected || hidpp->delayed_input)
>   return;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

Previously wtp_raw_event would be called through
hidpp_raw_hidpp_event (for the touchpad report) and hidpp_raw_event
(for the mouse report).

This patch removes one calling surface, making a clearer distinction
between "generic HID++ processing" (matching internal reports) and
device-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, added R-b of Benjamin

Hi Benjamin,

I am in a good mood now, so here is v3!

IMO 'r' as 'ret' is common just like 'i' is short for 'index', but for
consistency sake I'll use ret here ;)

Kind regards,
Peter
---
 drivers/hid/hid-logitech-hidpp.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2f1b0ac..18af2de 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -942,7 +942,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device 
*hidpp, u8 *data,
 
/*
 * If the mutex is locked then we have a pending answer from a
-* previoulsly sent command
+* previously sent command.
 */
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
/*
@@ -973,9 +973,6 @@ static int hidpp_raw_hidpp_event(struct hidpp_device 
*hidpp, u8 *data,
return 1;
}
 
-   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
-   return wtp_raw_event(hidpp->hid_dev, data, size);
-
return 0;
 }
 
@@ -983,7 +980,9 @@ static int hidpp_raw_event(struct hid_device *hdev, struct 
hid_report *report,
u8 *data, int size)
 {
struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+   int ret = 0;
 
+   /* Generic HID++ processing. */
switch (data[0]) {
case REPORT_ID_HIDPP_LONG:
if (size != HIDPP_REPORT_LONG_LENGTH) {
@@ -991,16 +990,23 @@ static int hidpp_raw_event(struct hid_device *hdev, 
struct hid_report *report,
size);
return 1;
}
-   return hidpp_raw_hidpp_event(hidpp, data, size);
+   ret = hidpp_raw_hidpp_event(hidpp, data, size);
+   break;
case REPORT_ID_HIDPP_SHORT:
if (size != HIDPP_REPORT_SHORT_LENGTH) {
hid_err(hdev, "received hid++ report of bad size (%d)",
size);
return 1;
}
-   return hidpp_raw_hidpp_event(hidpp, data, size);
+   ret = hidpp_raw_hidpp_event(hidpp, data, size);
+   break;
}
 
+   /* If no report is available for further processing, skip calling
+* raw_event of subclasses. */
+   if (ret != 0)
+   return ret;
+
if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
return wtp_raw_event(hdev, data, size);
 
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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
---
 drivers/hid/hid-logitech-hidpp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index b32f751..2f1b0ac 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -805,6 +805,11 @@ static int wtp_raw_event(struct hid_device *hdev, u8 
*data, int size)
 
switch (data[0]) {
case 0x02:
+   if (size < 2) {
+   hid_err(hdev, "Received HID report of bad size (%d)",
+   size);
+   return 1;
+   }
if (hidpp->quirks & HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS) {
input_event(wd->input, EV_KEY, BTN_LEFT,
!!(data[1] & 0x01));
@@ -818,6 +823,7 @@ static int wtp_raw_event(struct hid_device *hdev, u8 *data, 
int size)
return wtp_mouse_raw_xy_event(hidpp, &data[7]);
}
case REPORT_ID_HIDPP_LONG:
+   /* size is already checked in hidpp_raw_event. */
if ((report->fap.feature_index != wd->mt_feature_index) ||
(report->fap.funcindex_clientid != EVENT_TOUCHPAD_RAW_XY))
return 1;
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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
---
 drivers/hid/hid-logitech-dj.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c917ab6..5bc6d80 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -962,10 +962,24 @@ static int logi_dj_raw_event(struct hid_device *hdev,
 
switch (data[0]) {
case REPORT_ID_DJ_SHORT:
+   if (size != DJREPORT_SHORT_LENGTH) {
+   dev_err(&hdev->dev, "DJ report of bad size (%d)", size);
+   return false;
+   }
return logi_dj_dj_event(hdev, report, data, size);
case REPORT_ID_HIDPP_SHORT:
-   /* intentional fallthrough */
+   if (size != HIDPP_REPORT_SHORT_LENGTH) {
+   dev_err(&hdev->dev,
+   "Short HID++ report of bad size (%d)", size);
+   return false;
+   }
+   return logi_dj_hidpp_event(hdev, report, data, size);
case REPORT_ID_HIDPP_LONG:
+   if (size != HIDPP_REPORT_LONG_LENGTH) {
+   dev_err(&hdev->dev,
+   "Long HID++ report of bad size (%d)", size);
+   return false;
+   }
return logi_dj_hidpp_event(hdev, report, data, size);
}
 
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

Previously wtp_raw_event would be called through
hidpp_raw_hidpp_event (for the touchpad report) and hidpp_raw_event
(for the mouse report).

This patch removes one calling surface, making a clearer distinction
between "generic HID++ processing" (matching internal reports) and
device-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 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2f1b0ac..3dcd59c 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -942,7 +942,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device 
*hidpp, u8 *data,
 
/*
 * If the mutex is locked then we have a pending answer from a
-* previoulsly sent command
+* previously sent command.
 */
if (unlikely(mutex_is_locked(&hidpp->send_mutex))) {
/*
@@ -973,9 +973,6 @@ static int hidpp_raw_hidpp_event(struct hidpp_device 
*hidpp, u8 *data,
return 1;
}
 
-   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
-   return wtp_raw_event(hidpp->hid_dev, data, size);
-
return 0;
 }
 
@@ -983,7 +980,9 @@ static int hidpp_raw_event(struct hid_device *hdev, struct 
hid_report *report,
u8 *data, int size)
 {
struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+   int r = 0;
 
+   /* Generic HID++ processing. */
switch (data[0]) {
case REPORT_ID_HIDPP_LONG:
if (size != HIDPP_REPORT_LONG_LENGTH) {
@@ -991,16 +990,23 @@ static int hidpp_raw_event(struct hid_device *hdev, 
struct hid_report *report,
size);
return 1;
}
-   return hidpp_raw_hidpp_event(hidpp, data, size);
+   r = hidpp_raw_hidpp_event(hidpp, data, size);
+   break;
case REPORT_ID_HIDPP_SHORT:
if (size != HIDPP_REPORT_SHORT_LENGTH) {
hid_err(hdev, "received hid++ report of bad size (%d)",
size);
return 1;
}
-   return hidpp_raw_hidpp_event(hidpp, data, size);
+   r = hidpp_raw_hidpp_event(hidpp, data, size);
+   break;
}
 
+   /* If no report is available for further processing, skip calling
+* raw_event of subclasses. */
+   if (r != 0)
+   return r;
+
if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
return wtp_raw_event(hdev, data, size);
 
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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.
> >
> > For the old WTP, I do not have a HID descriptor so just check for the
> > minimum length in hidpp_raw_event (this can be changed to an inequality
> > later).
> 
> Actually you have it :)
> All the DJ devices share the same report descriptors as they are
> provided by hid-logitech-dj :)

I see, I thought it was read from the hardware, but that probably
applies to the other interfaces. Looks like the report should have a
length of (16 + 12 * 2 + 8 + 8) / 8 = 7 bytes, correct?

> Anyway, the problem here would be with the bluetooth touchpad T651
> which sends its raw events over teh mouse (0x02) collection (hint:
> there is a "< 21" in wtp_raw_event :-P )

Huh, how can that be allowed if the mouse descriptor accept less? Does
the bluetooth layer pad the report somehow?

> >
> > 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.
> 
> "<" should be kept for the reason above.
> 
> >
> > Kind regards,
> > Peter
> > ---
> >  drivers/hid/hid-logitech-dj.c| 16 +++-
> >  drivers/hid/hid-logitech-hidpp.c | 12 +---
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > index c917ab6..5bc6d80 100644
> > --- a/drivers/hid/hid-logitech-dj.c
> > +++ b/drivers/hid/hid-logitech-dj.c
> > @@ -962,10 +962,24 @@ static int logi_dj_raw_event(struct hid_device *hdev,
> >
> > switch (data[0]) {
> > case REPORT_ID_DJ_SHORT:
> > +   if (size != DJREPORT_SHORT_LENGTH) {
> > +   dev_err(&hdev->dev, "DJ report of bad size (%d)", 
> > size);
> > +   return false;
> > +   }
> > return logi_dj_dj_event(hdev, report, data, size);
> > case REPORT_ID_HIDPP_SHORT:
> > -   /* intentional fallthrough */
> > +   if (size != HIDPP_REPORT_SHORT_LENGTH) {
> > +   dev_err(&hdev->dev,
> > +   "Short HID++ report of bad size (%d)", 
> > size);
> > +   return false;
> > +   }
> > +   return logi_dj_hidpp_event(hdev, report, data, size);
> > case REPORT_ID_HIDPP_LONG:
> > +   if (size != HIDPP_REPORT_LONG_LENGTH) {
> > +   dev_err(&hdev->dev,
> > +   "Long HID++ report of bad size (%d)", size);
> > +   return false;
> > +   }
> 
> This hunk is good to me.
> 
> > return logi_dj_hidpp_event(hdev, report, data, size);
> > }
> >
> > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > b/drivers/hid/hid-logitech-hidpp.c
> > index ae23dec..2315358 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -992,11 +992,17 @@ static int hidpp_raw_event(struct hid_device *hdev, 
> > struct hid_report *report,
> > return 1;
> > }
> > return hidpp_raw_hidpp_event(hidpp, data, size);
> > +   case 0x02:
> > +   if (size < 2) {
> > +   hid_err(hdev, "Received HID report of bad size 
> > (%d)",
> > +   size);
> > +   return 1;
> > +   }
> > +   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > +   return wtp_raw_event(hdev, data, size);
> > +   return 1;
> > }
> >
> > -   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > -   return wtp_raw_event(hdev, data, size);
> 
> This one is OK, but I don't like it.
> 
> wtp_raw_event also expects long hid++ reports, and I'd prefer having
> the raw_event() callback first checking on the generic hid++ reports,
> and then addressing the various subclasses of devices.
> After a better look at the code, it occurs that the actual code is
> already pretty

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

[Peter Wu]

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. Caught by... well, a bug in the QEMU emulation of this receiver.
> >
> > Renamed fap to rap for HID++ 1.0 errors because it is more logical,
> > it has no functional difference.
> >
> > Signed-off-by: Peter Wu 
> > ---
> 
> I'd like to have Nestor's opinion on this. I did not manage to find on
> the documentation that HID++ 2.0 Long report error code is 0xff, so
> introducing this change without Logitech's blessing would be
> unfortunate.
> I understand this will fix your qemu problem, but I am not entirely
> sure if we do not have to check on 0xff and 0x8f in both short and
> long responses.
> 
> Cheers,
> Benjamin

The error code was found by probing the hardware. The HID++ 2.0 spec
does define some error codes, for example an OutOfRange error when
GetFeatureID is called with a featureIndex greater than the available
features count. The documentation also defines the valid FeatureIndex
range as 1..254, so I thought it was reasonable to assume that 0xff is
the HID++ 2.0 error indicator.

Nestor, so far I have only seen the OutOfRange error when the arguments
are invalid. Are there other cases where HID++ 2.0 are reported instead
of HID++ 1.0?

QEMU was not the problem though, it was just a bug in my
usb-ltunify-receiver device emulation which exposed this missing check.

Kind regards,
Peter

> >  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-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -105,6 +105,7 @@ struct hidpp_device {
> >  };
> >
> >
> > +/* HID++ 1.0 error codes */
> >  #define HIDPP_ERROR0x8f
> >  #define HIDPP_ERROR_SUCCESS0x00
> >  #define HIDPP_ERROR_INVALID_SUBID  0x01
> > @@ -119,6 +120,8 @@ struct hidpp_device {
> >  #define HIDPP_ERROR_REQUEST_UNAVAILABLE0x0a
> >  #define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
> >  #define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
> > +/* HID++ 2.0 error codes */
> > +#define HIDPP20_ERROR  0xff
> >
> >  static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
> >
> > @@ -192,9 +195,16 @@ static int hidpp_send_message_sync(struct hidpp_device 
> > *hidpp,
> > }
> >
> > if (response->report_id == REPORT_ID_HIDPP_SHORT &&
> > -   response->fap.feature_index == HIDPP_ERROR) {
> > +   response->rap.sub_id == HIDPP_ERROR) {
> > +   ret = response->rap.params[1];
> > +   dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
> > +   goto exit;
> > +   }
> > +
> > +   if (response->report_id == REPORT_ID_HIDPP_LONG &&
> > +   response->fap.feature_index == HIDPP20_ERROR) {
> > ret = response->fap.params[1];
> > -   dbg_hid("__hidpp_send_report got hidpp error %02X\n", ret);
> > +   dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
> > goto exit;
> > }
> >
> > @@ -271,7 +281,8 @@ static inline bool hidpp_match_answer(struct 
> > hidpp_report *question,
> >  static inline bool hidpp_match_error(struct hidpp_report *question,
> > struct hidpp_report *answer)
> >  {
> > -   return (answer->fap.feature_index == HIDPP_ERROR) &&
> > +   return ((answer->rap.sub_id == HIDPP_ERROR) ||
> > +   (answer->fap.feature_index == HIDPP20_ERROR)) &&
> > (answer->fap.funcindex_clientid == question->fap.feature_index) 
> > &&
> > (answer->fap.params[0] == question->fap.funcindex_clientid);
> >  }
> > --
> > 2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 by... well, a bug in the QEMU emulation of this receiver.

Renamed fap to rap for HID++ 1.0 errors because it is more logical,
it has 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-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -105,6 +105,7 @@ struct hidpp_device {
 };
 
 
+/* HID++ 1.0 error codes */
 #define HIDPP_ERROR0x8f
 #define HIDPP_ERROR_SUCCESS0x00
 #define HIDPP_ERROR_INVALID_SUBID  0x01
@@ -119,6 +120,8 @@ struct hidpp_device {
 #define HIDPP_ERROR_REQUEST_UNAVAILABLE0x0a
 #define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
 #define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
+/* HID++ 2.0 error codes */
+#define HIDPP20_ERROR  0xff
 
 static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
 
@@ -192,9 +195,16 @@ static int hidpp_send_message_sync(struct hidpp_device 
*hidpp,
}
 
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
-   response->fap.feature_index == HIDPP_ERROR) {
+   response->rap.sub_id == HIDPP_ERROR) {
+   ret = response->rap.params[1];
+   dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
+   goto exit;
+   }
+
+   if (response->report_id == REPORT_ID_HIDPP_LONG &&
+   response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
-   dbg_hid("__hidpp_send_report got hidpp error %02X\n", ret);
+   dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
goto exit;
}
 
@@ -271,7 +281,8 @@ static inline bool hidpp_match_answer(struct hidpp_report 
*question,
 static inline bool hidpp_match_error(struct hidpp_report *question,
struct hidpp_report *answer)
 {
-   return (answer->fap.feature_index == HIDPP_ERROR) &&
+   return ((answer->rap.sub_id == HIDPP_ERROR) ||
+   (answer->fap.feature_index == HIDPP20_ERROR)) &&
(answer->fap.funcindex_clientid == question->fap.feature_index) &&
(answer->fap.params[0] == question->fap.funcindex_clientid);
 }
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

Hi Jiri,

Here are more fixes intended for the 3.19 tree after a review. Two bugfixes.
one which was mentioned in a mail with Benjamin ("avoid unintended
fall-through") and a fix to avoid a possible 5 second delay for HID++ 2.0
errors. I haven't encountered a case where the hidpp module generates a HID++
2.0 error though, so maybe that change can go to 3.20 too if you want to keep
the changeset small.

The third (second) patch adds a check to avoid passing a short report. A similar
fix should probably be written for stable kernels (the code was changed in 3.19,
but the length 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/hid-logitech-hidpp.c | 30 --
 2 files changed, 39 insertions(+), 7 deletions(-)

-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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.

For the old WTP, I do not have a HID descriptor so just check for the
minimum length in hidpp_raw_event (this can be changed to an inequality
later).

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/hid-logitech-hidpp.c | 12 +---
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c917ab6..5bc6d80 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -962,10 +962,24 @@ static int logi_dj_raw_event(struct hid_device *hdev,
 
switch (data[0]) {
case REPORT_ID_DJ_SHORT:
+   if (size != DJREPORT_SHORT_LENGTH) {
+   dev_err(&hdev->dev, "DJ report of bad size (%d)", size);
+   return false;
+   }
return logi_dj_dj_event(hdev, report, data, size);
case REPORT_ID_HIDPP_SHORT:
-   /* intentional fallthrough */
+   if (size != HIDPP_REPORT_SHORT_LENGTH) {
+   dev_err(&hdev->dev,
+   "Short HID++ report of bad size (%d)", size);
+   return false;
+   }
+   return logi_dj_hidpp_event(hdev, report, data, size);
case REPORT_ID_HIDPP_LONG:
+   if (size != HIDPP_REPORT_LONG_LENGTH) {
+   dev_err(&hdev->dev,
+   "Long HID++ report of bad size (%d)", size);
+   return false;
+   }
return logi_dj_hidpp_event(hdev, report, data, size);
}
 
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index ae23dec..2315358 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -992,11 +992,17 @@ static int hidpp_raw_event(struct hid_device *hdev, 
struct hid_report *report,
return 1;
}
return hidpp_raw_hidpp_event(hidpp, data, size);
+   case 0x02:
+   if (size < 2) {
+   hid_err(hdev, "Received HID report of bad size (%d)",
+   size);
+   return 1;
+   }
+   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
+   return wtp_raw_event(hdev, data, size);
+   return 1;
}
 
-   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
-   return wtp_raw_event(hdev, data, size);
-
return 0;
 }
 
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2315358..09eee17 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -811,6 +811,7 @@ static int wtp_raw_event(struct hid_device *hdev, u8 *data, 
int size)
input_event(wd->input, EV_KEY, BTN_RIGHT,
!!(data[1] & 0x02));
input_sync(wd->input);
+   return 0;
} else {
if (size < 21)
return 1;
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

On Thursday 11 December 2014 17:39:59 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.
> 
> 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 think that
is unlikely so there is no need to check for other strings.

> ---
> 
> Changes in v2:
> - renamed PREFIX_SIZE into PREFIX_LENGTH
> - changed "name_length + PREFIX_LENGTH;" into "PREFIX_LENGTH + name_length;"
> - rebased on Peter's last patch series
> 
>  drivers/hid/hid-logitech-hidpp.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 2f420c0..274dbb7 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -282,6 +282,33 @@ static inline bool hidpp_report_is_connect_event(struct 
> hidpp_report *report)
>   (report->rap.sub_id == 0x41);
>  }
>  
> +/**
> + * hidpp_prefix_name() prefixes the current given name with "Logitech ".
> + */
> +static void hidpp_prefix_name(char **name, int name_length)
> +{
> +#define PREFIX_LENGTH 9 /* "Logitech " */
> +
> + int new_length;
> + char *new_name;
> +
> + if (name_length > PREFIX_LENGTH &&
> + strncmp(*name, "Logitech ", PREFIX_LENGTH) == 0)
> + /* The prefix has is already in the name */
> + return;
> +
> + new_length = PREFIX_LENGTH + name_length;
> + new_name = kzalloc(new_length, GFP_KERNEL);
> + if (!new_name)
> + return;
> +
> + snprintf(new_name, new_length, "Logitech %s", *name);
> +
> + kfree(*name);
> +
> + *name = new_name;
> +}
> +
>  /* 
> -- */
>  /* HIDP++ 1.0 commands   
>  */
>  /* 
> -- */
> @@ -321,6 +348,10 @@ static char *hidpp_get_unifying_name(struct hidpp_device 
> *hidpp_dev)
>   return NULL;
>  
>   memcpy(name, &response.rap.params[2], len);
> +
> + /* include the terminating '\0' */
> + hidpp_prefix_name(&name, len + 1);
> +
>   return name;
>  }
>  
> @@ -498,6 +529,9 @@ static char *hidpp_get_device_name(struct hidpp_device 
> *hidpp)
>   index += ret;
>   }
>  
> + /* include the terminating '\0' */
> + hidpp_prefix_name(&name, __name_length + 1);
> +
>   return name;
>  }
>  
> 

-- 
Kind regards,
Peter
https://lekensteyn.nl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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
> > > error path. This avoids processing of HID reports when the probe fails
> > > which possibly leads to invalid memory access in hid_device_probe() as
> > > report_enum->report_id_hash might already be freed via
> > > hid_close_report().
> >
> > Well spotted too!
> >
> > >
> > > hid_set_drvdata() is called before wtp_allocate, be consistent and clear
> > > drvdata too on the error path of wtp_allocate.
> >
> > This is not strictly speaking required. We will have a dangling value in
> > hdev->private_data, but this should be overwritten before the next use.
> >
> > Anyway, it makes sense to clean up after a failure, so the patch is
> > Reviewed-by: Benjamin Tissoires 
> >
> > Cheers,
> > Benjamin
> >
> > >
> > > 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() be updated to ensure that hid_device_io_stop()
> > > gets called before probe() returns? Or should the hid-core be changed to
> > > handle this out-of-sync issue:
> 
> I do not have a strong opinion on this, and will defer to others. The
> reason I needed to communicate during probe() was to have the driver
> probe the actual device for details. In this use case, I would be okay
> to disable IO at the end of probe() and have it become reenabled via
> the normal (default) methods.
> 
> -andrew

Keeping the reports enabled when the probe succeeds is fine, I am
referring to the error path. If the probe fails, then reports should
never be accepted or a corruption may occur (if I see it correctly).

Is this analysis correct?

 hid_device_probe()
   hid_device_io_start()
   return FAILURE
 hid_close_report(device)
   report_enum = device
->report_enum[i]
   hid_free_report(report_enum
->report_id_hash[j])<-- NOTE: freed
... interrupt occurs ...
hid_input_report()
  hid_get_report()
report = report_enum->report_id_hash[n];
 ^ NOTE: use-after-free
return report if not NULL
  hdrv->raw_event(report) <--- BOOM?
   kfree(device->rdesc)
 device->driver = NULL

Kind regards,
Peter

> > >
> > >   if (ret) {
> > >   if (hdev->io_started))
> > >   down(&hdev->driver_input_lock);
> > >   hid_close_report(hdev);
> > >   hdev->driver = NULL;
> > >   }
> > >
> > > Is my observation correct or not that HID reports can arrive during
> > > hid_close_report() when io_started == true?
> > >
> > > Kind regards,
> > > Peter
> > > ---
> > >  drivers/hid/hid-logitech-hidpp.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index 4292cc3..2f420c0 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -1121,7 +1121,7 @@ static int hidpp_probe(struct hid_device *hdev, 
> > > const struct hid_device_id *id)
> > >   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP) {
> > >   ret = wtp_allocate(hdev, id);
> > >   if (ret)
> > > - return ret;
> > > + goto wtp_allocate_fail;
> > >   }
> > >
> > >   INIT_WORK(&hidpp->work, delayed_work_cb);
> > > @@ -1141,6 +1141,7 @@ static int hidpp_probe(struct hid_device *hdev, 
> > > const struct hid_device_id *id)
> > >   if (id->group != HID_GROUP_LOGITECH_DJ_DEVICE) {
> > >   if (!connected) {
> > >   hid_err(hdev, "Device not connected");
> > > + hid_device_io_stop(hdev);
> > >   goto hid_parse_fail;
> > >   }
> > >
> > > @@ -1186,6 +1187,7 @@ hid_hw_start_fail:
> > >  hid_parse_fail:
> > >   cancel_work_sync(&hidpp->work);
> > >   mutex_destroy(&hidpp->send_mutex);
> > > +wtp_allocate_fail:
> > >   hid_set_drvdata(hdev, NULL);
> > >   return ret;
> > >  }
> > > --
> > > 2.1.3
> > >

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 device list.
> > > 
> > > Prefixing the names with "Logitech " makes things better.
> > 
> > Doesn't this apply to all input devices? Like, every USB device can be
> > queried for the manufacturer which could then by included by the input
> > subsystem.
> 
> Yes and no. Yes, it's good to have the manufacturer name in the input
> subsystem, and no, because usbhid already prepend the name with the
> manufacturer.

I see, previously (and now, if the device name cannot be retrieved
because one unplugs the receiver during probe which I have actually
tested) a string such as "Logitech Unifying Device. Wireless PID:XXX"
shows up. Now the only string visible is "M512".

Speaking of errors retrieving the name, if a device is turned off then
the name cannot be queried using HID++ 2.0 (think of "T650" instead of
"Wireless Rechargeable Touchpad T650"). Wouldn't this confuse userspace
applications which rely on a constant name?

> > 
> > What about duplicate names? Can this patch cause a conflict with devices
> > having the same name?
> 
> I am not sure what you mean here. I am adding a prefix to the name, so I
> do not see how a conflict can be possible. If there were a "M705" and a
> "Logitech M705", with different wireless PID, that would be worrisome to
> some extend.
> But I am pretty sure this will not happen.

I thought that this name would be used for /dev/bus/hid/devices/XXX and
therefore had to be unique, but this is not the case (the name is
available under the input device). No worries then!

> > 
> > > Signed-off-by: Benjamin Tissoires 
> > > ---
> > > 
> > > Hi Jiri,
> > > 
> > > I'd love to see this one in 3.19 (after a strong review, of course).
> > > The idea came with the mouse DPI database that Peter is currently working 
> > > on
> > > (see 
> > > http://who-t.blogspot.com.au/2014/12/building-a-dpi-database-for-mice.html).
> > > 
> > > I think, if you do not qualify the series for 3.19, we should drop it 
> > > entirely.
> > > 3.19 introduces the hidpp module and changes the labels. The DPI hwdb 
> > > will check
> > > on the label to match the actual mouse, so if this one does not get into 
> > > 3.19,
> > > we will end up in 3 entries for each Logitech device.
> > > 
> > > Cheers,
> > > Benjamin
> > > 
> > > 
> > >  drivers/hid/hid-logitech-hidpp.c | 34 ++
> > >  1 file changed, 34 insertions(+)
> > > 
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index 3846305..8cf4352 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -282,6 +282,33 @@ static inline bool 
> > > hidpp_report_is_connect_event(struct hidpp_report *report)
> > >   (report->rap.sub_id == 0x41);
> > >  }
> > >  
> > > +/**
> > > + * hidpp_prefix_name() prefixes the current given name with "Logitech ".
> > > + */
> > > +static void hidpp_prefix_name(char **name, int name_length)
> > > +{
> > > +#define PREFIX_SIZE 9 /* "Logitech " */
> > > +
> > > + int new_length;
> > > + char *new_name;
> > > +
> > > + if (name_length > PREFIX_SIZE &&
> > > + strncmp(*name, "Logitech ", PREFIX_SIZE) == 0)
> > 
> > I think you meant || here, not &&.
> 
> No, I meant &&. The idea is to not add a prefix if the provided name
> already contains the prefix. Read that as "if the size of the name may
> contain the prefix and that the prefix is here, then we bail out".

Ah, I somehow read it as "if the name is longer than what can be
stored".

> > 
> > > + /* The prefix has is already in the name */
> > > + return;
> > > +
> > > + new_length = name_length + PREFIX_SIZE;
> > 
> > Stylistic note, but 'PREFIX_SIZE + name_length' would match the order of
> > the string that gets prepended.
> 
> Works for me.
> 
> I will send a v2 with your 

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

[Peter Wu]

hidpp_devicenametype_get_device_name() may return a negative value on
protocol errors (for example, when the device is powered off).
Explicitly check this condition to avoid a long-running loop.

(0 cannot be returned as __name_length - index > 0, but check for it
anyway as it would otherwise 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-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -484,10 +484,16 @@ static char *hidpp_get_device_name(struct hidpp_device 
*hidpp)
if (!name)
return NULL;
 
-   while (index < __name_length)
-   index += hidpp_devicenametype_get_device_name(hidpp,
+   while (index < __name_length) {
+   ret = hidpp_devicenametype_get_device_name(hidpp,
feature_index, index, name + index,
__name_length - index);
+   if (ret <= 0) {
+   kfree(name);
+   return NULL;
+   }
+   index += ret;
+   }
 
return name;
 }
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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-logitech-hidpp.c
index 4d72c20..4292cc3 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -313,6 +313,9 @@ static char *hidpp_get_unifying_name(struct hidpp_device 
*hidpp_dev)
 
len = response.rap.params[1];
 
+   if (2 + len > sizeof(response.rap.params))
+   return NULL;
+
name = kzalloc(len + 1, GFP_KERNEL);
if (!name)
return NULL;
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

Balance a hid_device_io_start() call with hid_device_io_stop() in the
error path. This avoids processing of HID reports when the probe fails
which possibly leads to invalid memory access in hid_device_probe() as
report_enum->report_id_hash might already be freed via
hid_close_report().

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() be updated to ensure that hid_device_io_stop()
gets called before probe() returns? Or should the hid-core be changed to
handle this out-of-sync issue:

if (ret) {
if (hdev->io_started))
down(&hdev->driver_input_lock);
hid_close_report(hdev);
hdev->driver = NULL;
}

Is my observation correct or not that HID reports can arrive during
hid_close_report() when io_started == true?

Kind regards,
Peter
---
 drivers/hid/hid-logitech-hidpp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 4292cc3..2f420c0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1121,7 +1121,7 @@ static int hidpp_probe(struct hid_device *hdev, const 
struct hid_device_id *id)
if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP) {
ret = wtp_allocate(hdev, id);
if (ret)
-   return ret;
+   goto wtp_allocate_fail;
}
 
INIT_WORK(&hidpp->work, delayed_work_cb);
@@ -1141,6 +1141,7 @@ static int hidpp_probe(struct hid_device *hdev, const 
struct hid_device_id *id)
if (id->group != HID_GROUP_LOGITECH_DJ_DEVICE) {
if (!connected) {
hid_err(hdev, "Device not connected");
+   hid_device_io_stop(hdev);
goto hid_parse_fail;
}
 
@@ -1186,6 +1187,7 @@ hid_hw_start_fail:
 hid_parse_fail:
cancel_work_sync(&hidpp->work);
mutex_destroy(&hidpp->send_mutex);
+wtp_allocate_fail:
hid_set_drvdata(hdev, NULL);
return ret;
 }
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 insertions(+), 13 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 1a6395d..5066df8 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -461,7 +461,7 @@ static int hidpp_devicenametype_get_device_name(struct 
hidpp_device *hidpp,
return count;
 }
 
-static char *hidpp_get_device_name(struct hidpp_device *hidpp, u8 *name_length)
+static char *hidpp_get_device_name(struct hidpp_device *hidpp)
 {
u8 feature_type;
u8 feature_index;
@@ -473,28 +473,23 @@ static char *hidpp_get_device_name(struct hidpp_device 
*hidpp, u8 *name_length)
ret = hidpp_root_get_feature(hidpp, HIDPP_PAGE_GET_DEVICE_NAME_TYPE,
&feature_index, &feature_type);
if (ret)
-   goto out_err;
+   return NULL;
 
ret = hidpp_devicenametype_get_count(hidpp, feature_index,
&__name_length);
if (ret)
-   goto out_err;
+   return NULL;
 
name = kzalloc(__name_length + 1, GFP_KERNEL);
if (!name)
-   goto out_err;
+   return NULL;
 
-   *name_length = __name_length + 1;
while (index < __name_length)
index += hidpp_devicenametype_get_device_name(hidpp,
feature_index, index, name + index,
__name_length - index);
 
return name;
-
-out_err:
-   *name_length = 0;
-   return NULL;
 }
 
 /* -- 
*/
@@ -989,7 +984,6 @@ static void hidpp_overwrite_name(struct hid_device *hdev, 
bool use_unifying)
 {
struct hidpp_device *hidpp = hid_get_drvdata(hdev);
char *name;
-   u8 name_length;
 
if (use_unifying)
/*
@@ -999,7 +993,7 @@ static void hidpp_overwrite_name(struct hid_device *hdev, 
bool use_unifying)
 */
name = hidpp_get_unifying_name(hidpp);
else
-   name = hidpp_get_device_name(hidpp, &name_length);
+   name = hidpp_get_device_name(hidpp);
 
if (!name)
hid_err(hdev, "unable to retrieve the name of the device");
@@ -1053,7 +1047,6 @@ static void hidpp_connect_event(struct hidpp_device 
*hidpp)
bool connected = atomic_read(&hidpp->connected);
struct input_dev *input;
char *name, *devm_name;
-   u8 name_length;
 
if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
wtp_connect(hdev, connected);
@@ -1080,7 +1073,7 @@ static void hidpp_connect_event(struct hidpp_device 
*hidpp)
return;
}
 
-   name = hidpp_get_device_name(hidpp, &name_length);
+   name = hidpp_get_device_name(hidpp);
if (!name) {
hid_err(hdev, "unable to retrieve the name of the device");
} else {
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

Hi Jiri,

Here are four patches intended for the 3.19 stream and are based on
jikos/hid (for-next, v3.18-rc4-144-gd9372ee).

* The first is actually from Benjamin Tissoires, but modified to remove
  a now unneeded goto.
* The second one depends on the first (it could work without, but there
  will be a context mismatch).
* The third one can be applied independently of the others and is needed
  to avoid a possible buffer overread.
* The fourth and final patch fixes an unbalanced hid_device_io_start().

Tested by booting with three paired USB devices (QEMU + USB
passthrough), two of them 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: disable io in probe error path

 drivers/hid/hid-logitech-hidpp.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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)
-   return 1;
-   return wtp_mouse_raw_xy_event(hidpp, &data[7]);
+   if (hidpp->quirks & HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS) {
+   input_event(wd->input, EV_KEY, BTN_LEFT,
+   !!(data[1] & 0x01));
+   input_event(wd->input, EV_KEY, BTN_RIGHT,
+   !!(data[1] & 0x02));
+   input_sync(wd->input);
+   } else {
+   if (size < 21)
+   return 1;
+   return wtp_mouse_raw_xy_event(hidpp, &data[7]);
+   }
case REPORT_ID_HIDPP_LONG:
if ((report->fap.feature_index != wd->mt_feature_index) ||
(report->fap.funcindex_clientid != EVENT_TOUCHPAD_RAW_XY))
return 1;
hidpp_touchpad_raw_xy_event(hidpp, data + 4, &raw);
 
wtp_send_raw_xy_event(hidpp, &raw);
return 0;
}

Report ID 2 is the mouse descriptor, so it seems correct in that it
falls-through to the next case, but I wanted to check with you that this
is indeed your intention. If so, could you explicitly mark it with a
comment, /* fallthrough */ ?
-- 
Kind regards,
Peter
https://lekensteyn.nl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 the extra code and simplify the API a bit.
> > > 
> > > Signed-off-by: Benjamin Tissoires 
> > >
> > > ---
> > >  drivers/hid/hid-logitech-hidpp.c | 10 +++---
> > >  1 file changed, 3 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c 
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index 1a6395d..3846305 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -461,7 +461,7 @@ static int 
> > > hidpp_devicenametype_get_device_name(struct hidpp_device *hidpp,
> > >   return count;
> > >  }
> > >  
> > > -static char *hidpp_get_device_name(struct hidpp_device *hidpp, u8 
> > > *name_length)
> > > +static char *hidpp_get_device_name(struct hidpp_device *hidpp)
> > >  {
> > >   u8 feature_type;
> > >   u8 feature_index;
> > > @@ -484,7 +484,6 @@ static char *hidpp_get_device_name(struct 
> > > hidpp_device *hidpp, u8 *name_length)
> > >   if (!name)
> > >   goto out_err;
> > >  
> > > - *name_length = __name_length + 1;
> > >   while (index < __name_length)
> > >   index += hidpp_devicenametype_get_device_name(hidpp,
> > >   feature_index, index, name + index,
> > 
> > hidpp_devicenametype_get_device_name can return a non-positive value if
> > the USB device is unplugged at the wrong time, or if a malicious device
> > is attached (and 0 is returned). An infinite loop is the result.
> 
> Oh, yes, you are definitively right.
> 
> > 
> > Can you apply this change in the patch or should I send you a separate
> > one?
> 
> Feel free to send your patch directly to the list.
> 
> > 
> > while (index < __name_length) {
> > ret = hidpp_devicenametype_get_device_name(hidpp,
> > feature_index, index, name + index,
> > __name_length - index);
> > if (ret <= 0) {
> > kfree(name);
> > return NULL;
> > }
> > index += ret;
> > }
> > 
> > > @@ -493,7 +492,6 @@ static char *hidpp_get_device_name(struct 
> > > hidpp_device *hidpp, u8 *name_length)
> > >   return name;
> > >  
> > >  out_err:
> > > - *name_length = 0;
> > >   return NULL;
> > 
> > What about dropping the label out_err here and returning NULL in the
> > previous places?
> 
> Yep, good idea. You can either send a patch for that if you want to take
> credits, or I can send a v2. It's up to you.
> 
> Cheers,
> Benjamin

I found another place where a boundary check is missing, but will treat
that in a separate patch. If you send a v2 with the return NULL fixed
up, I'll base my patch (to add a retval check) on yours.

Kind regards,
Peter

> > 
> > >  }
> > >  
> > > @@ -989,7 +987,6 @@ static void hidpp_overwrite_name(struct hid_device 
> > > *hdev, bool use_unifying)
> > >  {
> > >   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > >   char *name;
> > > - u8 name_length;
> > >  
> > >   if (use_unifying)
> > >   /*
> > > @@ -999,7 +996,7 @@ static void hidpp_overwrite_name(struct hid_device 
> > > *hdev, bool use_unifying)
> > >*/
> > >   name = hidpp_get_unifying_name(hidpp);
> > >   else
> > > - name = hidpp_get_device_name(hidpp, &name_length);
> > > + name = hidpp_get_device_name(hidpp);
> > >  
> > >   if (!name)
> > >   hid_err(hdev, "unable to retrieve the name of the device");
> > > @@ -1053,7 +1050,6 @@ static void hidpp_connect_event(struct hidpp_device 
> > > *hidpp)
> > >   bool connected = atomic_read(&hidpp->connected);
> > >   struct input_dev *input;
> > >   char *name, *devm_name;
> > > - u8 name_length;
> > >  
> > >   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > >   wtp_connect(hdev, connected);
> > > @@ -1080,7 +1076,7 @@ static void hidpp_connect_event(struct hidpp_device 
> > > *hidpp)
> > >   return;
> > >   }
> > >  
> > > - name = hidpp_get_device_name(hidpp, &name_length);
> > > + name = hidpp_get_device_name(hidpp);
> > >   if (!name) {
> > >   hid_err(hdev, "unable to retrieve the name of the device");
> > >   } else {
> > > 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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, every USB device can be
queried for the manufacturer which could then by included by the input
subsystem.

What about duplicate names? Can this patch cause a conflict with devices
having the same name?

> Signed-off-by: Benjamin Tissoires 
> ---
> 
> Hi Jiri,
> 
> I'd love to see this one in 3.19 (after a strong review, of course).
> The idea came with the mouse DPI database that Peter is currently working on
> (see 
> http://who-t.blogspot.com.au/2014/12/building-a-dpi-database-for-mice.html).
> 
> I think, if you do not qualify the series for 3.19, we should drop it 
> entirely.
> 3.19 introduces the hidpp module and changes the labels. The DPI hwdb will 
> check
> on the label to match the actual mouse, so if this one does not get into 3.19,
> we will end up in 3 entries for each Logitech device.
> 
> Cheers,
> Benjamin
> 
> 
>  drivers/hid/hid-logitech-hidpp.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 3846305..8cf4352 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -282,6 +282,33 @@ static inline bool hidpp_report_is_connect_event(struct 
> hidpp_report *report)
>   (report->rap.sub_id == 0x41);
>  }
>  
> +/**
> + * hidpp_prefix_name() prefixes the current given name with "Logitech ".
> + */
> +static void hidpp_prefix_name(char **name, int name_length)
> +{
> +#define PREFIX_SIZE 9 /* "Logitech " */
> +
> + int new_length;
> + char *new_name;
> +
> + if (name_length > PREFIX_SIZE &&
> + strncmp(*name, "Logitech ", PREFIX_SIZE) == 0)

I think you meant || here, not &&.

> + /* The prefix has is already in the name */
> + return;
> +
> + new_length = name_length + PREFIX_SIZE;

Stylistic note, but 'PREFIX_SIZE + name_length' would match the order of
the string that gets prepended.

Kind regards,
Peter

> + new_name = kzalloc(new_length, GFP_KERNEL);
> + if (!new_name)
> + return;
> +
> + snprintf(new_name, new_length, "Logitech %s", *name);
> +
> + kfree(*name);
> +
> + *name = new_name;
> +}
> +
>  /* 
> -- */
>  /* HIDP++ 1.0 commands   
>  */
>  /* 
> -- */
> @@ -318,6 +345,10 @@ static char *hidpp_get_unifying_name(struct hidpp_device 
> *hidpp_dev)
>   return NULL;
>  
>   memcpy(name, &response.rap.params[2], len);
> +
> + /* include the terminating '\0' */
> + hidpp_prefix_name(&name, len + 1);
> +
>   return name;
>  }
>  
> @@ -489,6 +520,9 @@ static char *hidpp_get_device_name(struct hidpp_device 
> *hidpp)
>   feature_index, index, name + index,
>   __name_length - index);
>  
> + /* include the terminating '\0' */
> + hidpp_prefix_name(&name, __name_length + 1);
> +
>   return name;
>  
>  out_err:
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Wu]

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 | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c 
> b/drivers/hid/hid-logitech-hidpp.c
> index 1a6395d..3846305 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -461,7 +461,7 @@ static int hidpp_devicenametype_get_device_name(struct 
> hidpp_device *hidpp,
>   return count;
>  }
>  
> -static char *hidpp_get_device_name(struct hidpp_device *hidpp, u8 
> *name_length)
> +static char *hidpp_get_device_name(struct hidpp_device *hidpp)
>  {
>   u8 feature_type;
>   u8 feature_index;
> @@ -484,7 +484,6 @@ static char *hidpp_get_device_name(struct hidpp_device 
> *hidpp, u8 *name_length)
>   if (!name)
>   goto out_err;
>  
> - *name_length = __name_length + 1;
>   while (index < __name_length)
>   index += hidpp_devicenametype_get_device_name(hidpp,
>   feature_index, index, name + index,

hidpp_devicenametype_get_device_name can return a non-positive value if
the USB device is unplugged at the wrong time, or if a malicious device
is attached (and 0 is returned). An infinite loop is the result.

Can you apply this change in the patch or should I send you a separate
one?

while (index < __name_length) {
ret = hidpp_devicenametype_get_device_name(hidpp,
feature_index, index, name + index,
__name_length - index);
if (ret <= 0) {
kfree(name);
return NULL;
}
index += ret;
}

> @@ -493,7 +492,6 @@ static char *hidpp_get_device_name(struct hidpp_device 
> *hidpp, u8 *name_length)
>   return name;
>  
>  out_err:
> - *name_length = 0;
>   return NULL;

What about dropping the label out_err here and returning NULL in the
previous places?

>  }
>  
> @@ -989,7 +987,6 @@ static void hidpp_overwrite_name(struct hid_device *hdev, 
> bool use_unifying)
>  {
>   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
>   char *name;
> - u8 name_length;
>  
>   if (use_unifying)
>   /*
> @@ -999,7 +996,7 @@ static void hidpp_overwrite_name(struct hid_device *hdev, 
> bool use_unifying)
>*/
>   name = hidpp_get_unifying_name(hidpp);
>   else
> - name = hidpp_get_device_name(hidpp, &name_length);
> + name = hidpp_get_device_name(hidpp);
>  
>   if (!name)
>   hid_err(hdev, "unable to retrieve the name of the device");
> @@ -1053,7 +1050,6 @@ static void hidpp_connect_event(struct hidpp_device 
> *hidpp)
>   bool connected = atomic_read(&hidpp->connected);
>   struct input_dev *input;
>   char *name, *devm_name;
> - u8 name_length;
>  
>   if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
>   wtp_connect(hdev, connected);
> @@ -1080,7 +1076,7 @@ static void hidpp_connect_event(struct hidpp_device 
> *hidpp)
>   return;
>   }
>  
> - name = hidpp_get_device_name(hidpp, &name_length);
> + name = hidpp_get_device_name(hidpp);
>   if (!name) {
>   hid_err(hdev, "unable to retrieve the name of the device");
>   } else {
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stupid NVIDIA 3D vgaarb.c patch

[Peter Wu]

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
> ---
> This is for Aorus X3 laptop with NVIDIA GTX 870m card
> 
> On Tue, Sep 23, 2014 at 3:43 AM, Linus Torvalds <
> torva...@linux-foundation.org> wrote:
> 
> > Adding proper people and mailing lists..
> >
> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> > appropriate, but hopefully somebody does. The fact that it makes
> > things work certainly argues fairly convincingly for it, but I want
> > some backup here.
> >
> > Dave, BenH?
> >
> > Christopher(?), can you please also specify which laptop etc. And the
> > patch itself seems to have come from somebody else, unless you're
> > Lekensteyn. So we'd want to get the provenance of that too.

If I understood this correctly, VGA arbitration is used to deal with multiple
users of a fixed IO memory address. I don't know whether modern software still
use it, but if they do, then it probably makes sense to include the 3D
controller class as some Nvidia graphics card are configured with this class.

Unfortunately I cannot provide more details than this as I don't know the
specifics. Feel free to take this patch and make it suitable for inclusion. I
don't have this kind of hardware, but mr. C is certainly not the only one with
this.

Kind regards,
Peter

> > Linus
> >
> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström 
> > wrote:
> > > Hi Linus,
> > >
> > > I don't know who the original author is and I can have one of the distro
> > > graphics friends review it, but I need this patch below to get NVIDIA
> > > drivers to work (without using any Intel graphics) on my laptop
> > > http://pastebin.com/wpmFi38k
> > >
> > > Sorry - I know this is not the proper way to submit a patch, but it's
> > > trivial and I'm not a kernel dev.
> > >
> > > Thanks
> > >
> > > ./C
> >

-- 
Kind regards,
Peter
https://lekensteyn.nl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 6/6] drivers/staging/rtl8821ae: replace magic number by macro

[Peter Wu]

(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/staging/rtl8821ae/rtl8821ae/hw.c  |2 +-
>  drivers/staging/rtl8821ae/rtl8821ae/reg.h |1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c 
> b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> index 1b8583b..1aa1661 100644
> --- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> +++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> @@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct 
> ieee80211_hw *hw,
>  
>   rtl_write_byte(rtlpriv, (MSR), bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & ~0xfc) == MSR_AP)
> + if ((bt_msr & MSR_MASK) == MSR_AP)
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
>   else
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> diff --git a/drivers/staging/rtl8821ae/rtl8821ae/reg.h 
> b/drivers/staging/rtl8821ae/rtl8821ae/reg.h
> index beffb42..4cb3ca9 100644
> --- a/drivers/staging/rtl8821ae/rtl8821ae/reg.h
> +++ b/drivers/staging/rtl8821ae/rtl8821ae/reg.h
> @@ -431,6 +431,7 @@
>  #define  MSR_ADHOC   0x01
>  #define  MSR_INFRA   0x02
>  #define  MSR_AP  0x03
> +#define  MSR_MASK0x03
>  
>  #define  RRSR_RSC_OFFSET 21
>  #define  RRSR_SHORT_OFFSET   23
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 0/6] rtlwifi: Fix incorrect MSR mask

[Peter Wu]

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 consistency.

LGTM for all 6 patches. Reviewed-by was added with permission in a
private conversation.

> Rickard Strandqvist (1):
>   rtlwifi: Fix media status register mask AND Replace magic number by macro

This looks a bit unfortunate, next time just wipe old patches and
generate new ones with git-format-patch, then use the command
git-send-email patches/*. In that way, the threading stays intact.

Kind regards,
Peter

>  drivers/net/wireless/rtlwifi/rtl8188ee/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8188ee/reg.h |1 +
>  drivers/net/wireless/rtlwifi/rtl8192ce/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8192ce/reg.h |1 +
>  drivers/net/wireless/rtlwifi/rtl8192cu/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8192de/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8192de/reg.h |1 +
>  drivers/net/wireless/rtlwifi/rtl8723ae/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8723ae/reg.h |1 +
>  drivers/net/wireless/rtlwifi/rtl8723be/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8723be/reg.h |1 +
>  drivers/staging/rtl8821ae/rtl8821ae/hw.c |2 +-
>  drivers/staging/rtl8821ae/rtl8821ae/reg.h|1 +
>  13 files changed, 13 insertions(+), 7 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up if statement that always evaluates to false

[Peter Wu]

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
is fine.

Don't forget those other drivers. You are aware that the *e drivers are for 
PCI(e)
devices, and *u for USB right?

Kind regards,
Peter

> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/net/wireless/rtlwifi/rtl8192de/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8192de/reg.h |1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> index 2b08671..280c3da 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> @@ -1128,7 +1128,7 @@ static int _rtl92de_set_media_status(struct 
> ieee80211_hw *hw,
>   }
>   rtl_write_byte(rtlpriv, REG_CR + 2, bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & 0xfc) == MSR_AP)
> + if ((bt_msr & MSR_MASK) == MSR_AP)
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
>   else
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/reg.h 
> b/drivers/net/wireless/rtlwifi/rtl8192de/reg.h
> index 7f29b8d..315a298 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192de/reg.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192de/reg.h
> @@ -369,6 +369,7 @@
>  #define  MSR_ADHOC   0x01
>  #define  MSR_INFRA   0x02
>  #define  MSR_AP  0x03
> +#define  MSR_MASK0x03
>  
>  /* 6. Adaptive Control Registers  (Offset: 0x0160 - 0x01CF) */
>  /* - */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] net: wireless: rtlwifi: rtl8192cu: hw.c: Cleaning up if statement that always evaluates to false

[Peter Wu]

On Saturday 21 June 2014 23:00:37 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.

The subject is still wrong (it is not a cleanup, but a fix) and the
commit message could also be improved (no need to mention the
discussion, just say why it was necessary and what you did to fix it).

Suggested text:

rtlwifi/rtl8192c[eu]: fix media status register mask

bt_msr & 0xfc will never match 0x3. Fix this by using a mask that
actually 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 example, then you can generate your patches with:

mkdir /tmp/patches
git format-patch --cover-letter -o /tmp/patches/ HEAD~3

Then review the files in /tmp/patches/ and if you are satisfied:

git send-email --to linux-wireless@... --cc ... /tmp/patches/*

Kind regards,
Peter

> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/net/wireless/rtlwifi/rtl8192ce/hw.c  |2 +-
>  drivers/net/wireless/rtlwifi/rtl8192ce/reg.h |1 +
>  drivers/net/wireless/rtlwifi/rtl8192cu/hw.c  |2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
> index 55adf04..5050938 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
> @@ -1206,7 +1206,7 @@ static int _rtl92ce_set_media_status(struct 
> ieee80211_hw *hw,
>  
>   rtl_write_byte(rtlpriv, (MSR), bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & 0xfc) == MSR_AP)
> + if ((bt_msr & MSR_MASK) == MSR_AP)
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
>   else
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/reg.h 
> b/drivers/net/wireless/rtlwifi/rtl8192ce/reg.h
> index ed703a1..dc8460c 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192ce/reg.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/reg.h
> @@ -375,6 +375,7 @@
>  #define  MSR_ADHOC   0x01
>  #define  MSR_INFRA   0x02
>  #define  MSR_AP  0x03
> +#define  MSR_MASK0x03
>  
>  #define  RRSR_RSC_OFFSET 21
>  #define  RRSR_SHORT_OFFSET   23
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
> index 07cb06d..87c0a27 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
> @@ -1360,7 +1360,7 @@ static int _rtl92cu_set_media_status(struct 
> ieee80211_hw *hw,
>   }
>   rtl_write_byte(rtlpriv, (MSR), bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & 0xfc) == MSR_AP)
> + if ((bt_msr & MSR_MASK) == MSR_AP)
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
>   else
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Writing watchdog_thresh triggers BUG: sleeping function called from invalid context

[Peter Wu]

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.
> > 
> > It was originally found on bare metal, since then reproduced in QEMU in
> > init, and when directly executing it.
> > 
> > Regards,
> > Peter
> 
> Hi Peter,
> 
> I assume the following patch will work?

Yes, the patch works (no more BUG). No idea whether it is
(in)correct though.

Regards,
Peter

> Michal, do you remember why we needed preempt here?  I wouldn't think it
> mattered as we are not doing anything per-cpu specific.
> 
> Cheers,
> Don
> 
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 516203e..30e4822 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -527,10 +527,8 @@ static void update_timers_all_cpus(void)
>   int cpu;
>  
>   get_online_cpus();
> - preempt_disable();
>   for_each_online_cpu(cpu)
>   update_timers(cpu);
> - preempt_enable();
>   put_online_cpus();
>  }
>  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] net: wireless: rtlwifi: rtl8188ee: hw.c: Cleaning up if statement that always evaluates to false

[Peter Wu]

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 thread, use something like:

Link: http://lkml.kernel.org/r/MESSAGE_ID_HERE

... but it would even be better if you *explain* why the previous behavior
is wrong, and what this patch does in an attempt to fix that.

> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/net/wireless/rtlwifi/rtl8188ee/hw.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> index 94cd9df..9bdac68 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> @@ -1231,7 +1231,7 @@ static int _rtl88ee_set_media_status(struct 
> ieee80211_hw *hw,
>  
>   rtl_write_byte(rtlpriv, (MSR), bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & 0xfc) == MSR_AP)
> + if ((bt_msr & MSR_MASK) == MSR_AP)

There is no such constant as MSR_MASK. Please compile test before sending.

>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
>   else
>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> 

Kind regards,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false

[Peter Wu]

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 other reply? Use git-format-patch --cover-letter.
Why would you need 35 mails? A commit should logically group a
change per driver. So, one commit probably touches rtl/reg.h
and rtl/hw.c (perhaps others? grep for it!)

Be sure to manually check each change. Your last patchset included
non-sensial commit messages and subjects.

> Then the macro I should add in all the:
> 
> net/wireless/rtlwifi/rtlse/reg.h
> 
> 
> And in the:
> drivers/staging/rtl8188eu/include/rtl8188e_spec.h
> drivers/staging/rtl8192e/rtl8192e/r8192E_hw.h
> drivers/staging/rtl8712/rtl871x_wlan_sme.h
> drivers/staging/rtl8723au/include/rtl8723a_spec.h
> drivers/staging/rtl8821ae/rtl8821ae/reg.h

The staging drivers will be taken by Greg KH, see MAINTAINERS
for the addresses for staging drivers.

> And should I put it like:
> #define MSR_MASK 0x03
> 
> Or is this more accurate:
> #define MSR_MASK   (MSR_INFRA | MSR_ADHOC)

Since the integer resulting from the mask is a decimal sequence rather
than a bitmap, it makes more sense to use 0x03 instead. Please have a
look at the drivers and be sure to understand why the changes are needed.

Peter

PS. please do not top-post. For driver discussions, you should keep
the list cc'd too. That makes it more likely for someone to respond to
such queries.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v3.13,v3.15] XHCI breaks suspend, causes overheating

[Peter Wu]

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:
Distribution: Arch Linux x86_64
USB peripheral: Samsung S3 (GT-i9300) phone
USB HCD: 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host 
Controller [1033:0194] (rev 03)
Kernel: v3.15-rc8-105-gc593e89 (also confirmed for v3.13.6, other kernels have 
not been tested)

I managed to get the following backtrace with SysRq + l:

NMI backtrace for cpu 0
CPU: 0 PID: 11849 Comm: kworker/0:2 Tainted: G   O  
3.15.0-rc8-custom-00058-gd2cfd31 #1
Hardware name: CLEVO CO.B7130   
/B7130   , BIOS 6.00 08/27/2010
Workqueue: pm pm_runtime_work
<..>
[] ? _raw_spin_unlock_irqrestore+0x5f/0x80
[] xhci_hub_control+0xbb/0x1450 [xhci_hcd]
[] ? usb_hcd_submit_urb+0x2dc/0xa80
[] usb_hcd_submit_urb+0x3c7/0xa80
[] ? mark_held_locks+0x75/0xa0
[] ? __raw_spin_lock_init+0x21/0x60
[] ? lockdep_init_map+0x61/0x530
[] usb_submit_urb+0x372/0x600
[] usb_start_wait_urb+0x5f/0x150
[] ? get_parent_ip+0xd/0x50
[] usb_control_msg+0xc5/0x110
[] hub_port_status+0x7c/0x120
[] hub_activate+0xc9/0x620
[] ? trace_hardirqs_on_caller+0x15d/0x200
[] hub_resume+0x31/0x70
[] usb_resume_interface.isra.5+0xb6/0x120
[] usb_suspend_both+0xf8/0x1f0
[] usb_runtime_suspend+0x33/0x80
[] ? usb_probe_interface+0x330/0x330
[] __rpm_callback+0x32/0x70
[] rpm_callback+0x26/0xa0
[] rpm_suspend+0x111/0x660
[] __pm_runtime_suspend+0x5d/0x90
[] ? usb_runtime_resume+0x20/0x20
[] usb_runtime_idle+0x2a/0x40
[] __rpm_callback+0x32/0x70
[] rpm_idle+0x27a/0x310
[] pm_runtime_work+0xbf/0xd0
[] process_one_work+0x1d4/0x560
[] ? process_one_work+0x174/0x560
[] worker_thread+0x12c/0x3d0
[] ? manage_workers.isra.23+0x2e0/0x2e0
[] kthread+0xf6/0x110
[] ? kthread_create_on_node+0x200/0x200
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x200/0x200

/proc/../stack was not usable, it just showed start_worker (iirc) on
top. `perf report` mentions kworker and khubd as top users with
call traces corresponding to the above backtrace. CPU usage increased a
bit, but the machine was "kind of usable":

root 11856  1.2  0.0  0 0 ?S00:51   0:10 
[kworker/0:3]
peter  555  1.8  1.1 3085412 87532 ?   Sl   Jun09   1:48 kwin
root 3  1.9  0.0  0 0 ?SJun09   1:54 
[ksoftirqd/0]
root14  1.9  0.0  0 0 ?SJun09   1:53 
[ksoftirqd/1]
peter  561  2.1  2.4 3373080 193416 ?  Sl   Jun09   2:06 kdeinit4: 
plasma-desktop [kdeinit]
root 11707  2.4  0.0  0 0 ?S00:36   0:40 
[kworker/1:3]
root   354  2.5  1.0 312392 82996 tty7 Ssl+ Jun09   2:27 /usr/bin/X 
:0 vt7 -nolisten tcp -auth /var/run/xauth/A:0-dfgwjb
root39  4.5  0.0  0 0 ?SJun09   4:24 [khubd]
root 11629 12.9  0.0  0 0 ?S00:33   4:02 
[kworker/1:2]
root 12076 14.6  0.0  0 0 ?S01:02   0:17 
[kworker/1:0]
root 11849 16.5  0.0  0 0 ?S00:44   3:25 
[kworker/0:2]

In an attempt to get more details, I executed:

echo workqueue:workqueue_queue_work > tracing/set_event
cat /sys/kernel/debug/tracing/trace_pipe | pv > /tmp/trace.txt

When the bug is triggered, I see 100k events/s with lines such as:

khubd-39[000] d..3  7342.846004: workqueue_queue_work: work 
struct=8800ae0f0ab8 function=pm_runtime_work workqueue=8802326bde00 
req_cpu=256 cpu=0

Attempts to suspend the laptop again failed consistently. After some
tries, the laptop began to beep (presumably thermal limits). I have
never heard such beeps before, the laptop has never been overheating.



Today, I tried to reproduce this bug again. The reproduction steps are:

 1. Start the ADB server (`adb shell`). There is no device connected
yet.
 2. Connect phone to USB 3.0 port (USB debugging is enabled on the
Android phone).
 3. Try to suspend.
 4. If it wakes up again, try to suspend again. Be sure that the USB
device is recognized by the laptop, and that the connection is seen
by the phone as well.

Expected results: laptop should sleep, phone may (or may not) continue
charging.

Actual results:
 - laptop wakes up immediately.
 - (case 1) kworkers are hogging CPU (seen on v3.15-rc8-ish and 3.13.6).
 - (case 2) Temperature raises (I have seen seen 110 degree Celsius
   before I quickly shut the laptop via the menu. Normal temperature is
   between 40-50 °C). Looking in `ps`, I see over 100 kworker processes.

Other information:
When the bug (case 1)

Re: [PATCH] net: wireless: rtlwifi: rtl8723be: hw.c: Cleaning up if statement that always evaluates to false

[Peter Wu]

(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 to something more suitable.

Right, do not forget to use [PATCH v2] as prefix and adjust the subject
too as this is no longer just "cleaning up a statement that always
evaluates to false", but rather "fix [insert stuff here] mask" (for
the 0xfc cases). The commit message must describe why the change is
beneficial, see other commit messages for examples.

Kind regards,
Peter

> 2014-06-08 22:35 GMT+02:00 David Rientjes :
> > On Sun, 8 Jun 2014, Rickard Strandqvist wrote:
> >
> >> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always 
> >> false
> >>
> >
> > Where is the 0xfc that your converting?
> >
> >> After pointing this out, Larry Finger informed what would be the correct 
> >> one.
> >> '(X & 0x3) == 0x3'
> >>
> >
> > This is already what it is, just say that you're replacing it with the
> > constant.
> >
> >> Signed-off-by: Rickard Strandqvist 
> >> ---
> >>  drivers/net/wireless/rtlwifi/rtl8723be/hw.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c 
> >> b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c
> >> index 0fdf090..b61044f 100644
> >> --- a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c
> >> +++ b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c
> >> @@ -1197,7 +1197,7 @@ static int _rtl8723be_set_media_status(struct 
> >> ieee80211_hw *hw,
> >>   }
> >>   rtl_write_byte(rtlpriv, (MSR), bt_msr);
> >>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> >> - if ((bt_msr & 0x03) == MSR_AP)
> >> + if ((bt_msr & MSR_AP) == MSR_AP)
> >>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
> >>   else
> >>   rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false

[Peter Wu]

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 patches.
One or two days should give people some time to read and reply.

As for MSR_MASK, that macro does not exist yet, I was wondering whether
it's OK to add a new macro? (Larry?)

> Sure, I can send a patch for all the files instead. However, earlier
> received complaints when I sent patches extending over more than one
> file.
> 
> I'll check again how the cover letter works. Although when I try with
> my send patch mail script it did not work as I wanted.

See the manual page git-send-email(1) and git-format-patch(1). In
particular the Example section of git-send-email(1).

Kind regards,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false

[Peter Wu]

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. 
> Please be careful.
> 
>  From everything I see, the test in all drivers should be
> 
> if ((bt_msr & MSR_AP) == MSR_AP)

That only happens to be case because MSR_INFRA | MSR_ADHOC == MSR_AP. This
seems to be the intent:

#define MSR_MASK 0x03
if ((bt_msr & MSR_MASK) == MSR_AP)

In rtl8192se, there are also MSR_LINK_... constants covering MSR_...
and in addition, there is a MSR_LINK_MASK. These macros are quite
redundant though given the other definitions, but the mask is still
nice to have I guess.

Also, personally I would submit just one patch touching all drivers, but
I see that Rickard has submitted a bunch of patches (without cover letter
either, making it more difficult to group them). What would you prefer,
a single patch touching multiple drivers (as the changes are mostly the
same) or split patches?

Kind regards,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false

[Peter Wu]

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 statement that is needed.
> 
> This was partly found using a static code analysis program called cppcheck.
> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/net/wireless/rtlwifi/rtl8192de/hw.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c 
> b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> index 2b08671..a1520d5 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> @@ -1128,10 +1128,7 @@ static int _rtl92de_set_media_status(struct 
> ieee80211_hw *hw,
>   }
>   rtl_write_byte(rtlpriv, REG_CR + 2, bt_msr);
>   rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & 0xfc) == MSR_AP)

If you look a few lines up, then you see that bt_msr is OR-ed with MSR_AP
for AP interfaces. The 0xfc should be 0x03, see other drivers for example:

rtl8723ae/hw.c:1112:if ((bt_msr & 0x03) == MSR_AP)
rtl8723be/hw.c:1200:if ((bt_msr & 0x03) == MSR_AP)
rtl8192cu/hw.c:1363:if ((bt_msr & 0xfc) == MSR_AP)
rtl8192ce/hw.c:1209:if ((bt_msr & 0xfc) == MSR_AP)
rtl8188ee/hw.c:1234:if ((bt_msr & 0xfc) == MSR_AP)
rtl8192de/hw.c:1131:if ((bt_msr & 0xfc) == MSR_AP)

> - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
> - else
> - rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
> + rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
>   return 0;
>  }

Kind regards,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

aes-x86_64 seems slower than the generic implementation

[Peter Wu]

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/linux-custom/config
 * CPU: Intel i5-460M
 * Distro: Arch Linux x86_64

Command:

   for i in {0..10};do cryptsetup benchmark --cipher aes-xts; done

Test results for n=11, mean (+ standard deviation), enc/dec:

 * aes-x86_64:  139.6 (0.68) / 138.5 (0.22)
 * aes-generic: 144.8 (0.63) / 144.6 (0.31)


About a month ago, I conducted a similar test on a different machine[1].

 * cryptsetup 1.6.4
 * QEMU: 1.7.0
 * Linux (guest, no modules): v3.14-rc7-59-g08edb33
 * Linux (host): v3.14-rc5
 * CPU: Intel i7-3770

Test results comparing aes-generic, aes-x86_64 and AESNI (n=3):

   generic x86_64  aesni
 * aes-cbc-128 201/276 200/280 669/2500
 * aes-cbc-256 162/205 159/208 492/1835
 * aes-xts-256 275/270 272/276 2050/2034
   (note, AES-NI performance varies a lot)

Aren't the assembly implementations supposed to be faster?

Kind regards,
Peter
 
 [1]: https://lekensteyn.nl/files/linux-crypto-benchmark/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Locking issues in "mmc: rtsx: add support for pre_req and post_req" (was: Re: [PATCH] mmc: rtsx: fix possible circular locking dependency)

[Peter Wu]

So, I reverted c42deffd5b53c9e583d83c7964854ede2f12410d ("mmc: rtsx: add 
support for pre_req and post_req") on top of v3.15-rc1-49-g10ec34f and the 
hang issue went away.

There is something that is possibly problematic. All three tasklets (cmd, 
data, finish) try to spinlock on host->lock. According to the tasklets 
documentation[1], they always run at interrupts (i.e., at any time, possibly 
right after tasklet_schedule if I got this right?).

These tasklets however do get scheduled *under* the host->lock which will 
cause a deadlock. This proposed patch ("mmc: rtsx: fix possible circular 
locking dependency") fixes the issue for sd_isr_done_transfer, but there are 
others:

1. sd_request_timeout:
 125 spin_lock_irqsave(&host->lock, flags);
 ...
 139 out:
 140 tasklet_schedule(&host->finish_tasklet); // <--
 141 spin_unlock_irqrestore(&host->lock, flags);

2. sd_get_rsp (cmd_tasklet!):
 429 spin_lock_irqsave(&host->lock, flags);
 ...
 506 tasklet_schedule(&host->finish_tasklet); // <--
 507 spin_unlock_irqrestore(&host->lock, flags);

3. sd_finish_multi_rw (data_tasklet!):
 657 spin_lock_irqsave(&host->lock, flags);
 ...
 684 tasklet_schedule(&host->finish_tasklet); // <--
 685 spin_unlock_irqrestore(&host->lock, flags);

4. sdmmc_request:
 921 mutex_lock(&pcr->pcr_mutex);
 922 spin_lock_irqsave(&host->lock, flags);
 ...
 967 tasklet_schedule(&host->finish_tasklet); // <--
 968 spin_unlock_irqrestore(&host->lock, flags);

5. rtsx_pci_sdmmc_drv_remove:
  1526 spin_lock_irqsave(&host->lock, flags);
  1527 if (host->mrq) {
  ...
  1541 tasklet_schedule(&host->finish_tasklet); // <--
  1542 }
  1543 spin_unlock_irqrestore(&host->lock, flags);
  1544 
  1545 del_timer_sync(&host->timer);
  1546 tasklet_kill(&host->cmd_tasklet);
  1547 tasklet_kill(&host->data_tasklet);
  1548 tasklet_kill(&host->finish_tasklet); // <--

pcr_mutex (un)locking:
 - gets locked in sdmmc_request
 - gets unlocked in sd_finish_request (finish_tasklet).
 - gets locked/unlocked in sdmmc_set_ios
 - gets locked/unlocked in sdmmc_get_ro
 - gets locked/unlocked in sdmmc_get_cd
 - gets locked/unlocked in sdmmc_switch_voltage
 - gets locked/unlocked in sdmmc_execute_tuning

finish_tasklet (sd_finish_request()) gets scheduled in:
 - sd_request_timeout (under host->lock; called on timer expiration)
 - error path of sd_send_cmd
 - get_rsp (cmd_tasklet; under host->lock)
 - error path of sd_start_multi_rw (after mod timer)
 - sd_finish_multi_rw (under host->lock)
 - sdmmc_request (under host->lock in error path; without host->lock
   elsewhere)
 - rtsx_pci_sdmmc_drv_remove (under host->lock)

sd_request_timeout (timer) related:
 - deleted in sd_finish_request under host->lock (also assumes pcr_mutex)
 - sd_send_cmd (timer set with 100ms timeout, not called in error path)
 - sd_start_multi_rw (timeout set to 10 HZ, called before error path is
   checked in which finish_tasklet gets scheduled)
Note: sd_request_timeout claims+releases host->lock.

If I understand it correctly, host->lock is responsible for protecting the 
realtek_pci_sdmmc structure. Why is tasklet_schedule() on the same lock?

Shouldn't the above five tasklet_schedule calls be moved outside the lock? 
Will 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 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 
> > 
> > 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->lock already
> > acquired. Since in sd_isr_done_transfer() the only work we do is schdule
> > tasklet, the cmd_tasklet and data_tasklet never conflict, so it is safe
> > to remove spin_lock() here.
> > 
> > Signed-off-by: Micky Ching 
> > ---
> > 
> >  drivers/mmc/host/rtsx_pci_sdmmc.c |4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> This patch came from
> https://lkml.kernel.org/r/534de1d7.3000...@realsil.com.cn ("Re:
> rtsx_pci_sdmmc lockdep splat").
> 
> With v3.15-rc1-49-g10ec34f, I have a hung machine when inserting a SD card.
> lockdep was not enabled for the kernel, I have not bisected yet

Re: [PATCH] mmc: rtsx: fix possible circular locking dependency

[Peter Wu]

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->lock already
> acquired. Since in sd_isr_done_transfer() the only work we do is schdule
> tasklet, the cmd_tasklet and data_tasklet never conflict, so it is safe
> to remove spin_lock() here.
> 
> Signed-off-by: Micky Ching 
> ---
>  drivers/mmc/host/rtsx_pci_sdmmc.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

This patch came from https://lkml.kernel.org/r/534de1d7.3000...@realsil.com.cn
("Re: rtsx_pci_sdmmc lockdep splat").

With v3.15-rc1-49-g10ec34f, I have a hung machine when inserting a SD card.
lockdep was not enabled for the kernel, I have not bisected yet.
This patch on top of that kernel version does not help (tested by
rmmod rtsx_pci_sdmmc and insmod the patched one).

Console (as typed over from a picture, sorry for any typos):
WARNING: CPU: 1 PID: 0 at kernel/locking/mutex.c:698
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in: ...
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15-rc1-custom-49-g10ec34f #5
Hardware name: Shuttle Inc. XS36V/XS36V, BIOS 1.11 12/18/2012
Call trace:
 dump_stack
warn_slowpath_common
warn_slowpath_fmt
__mutex_unlock_slowpath
mutex_unlock
sd_finish_request [rtsx_pci_sdmmc]
tasklet_action
__do_softirq
irq_exit
smp_apic_timer_interrupt
apic_timer_interrupt
 ? cpuidle_enter_state
cpuidle_enter
cpu_startup_entry
start_secondary
---[end trace ...]---
(60 seconds later:)
INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 1, t=18004 
jiffies, g=3264, c=3263, q=2)
INFO: Stall ended before state dump start

I also managed to get this trace about 106 seconds later when switching TTY:
INFO: task kworker/... blocked for more than 120 seconds
Workqueue: kmmcd mm_rescan [mmc_core]
Call trace:
? update_rq_clock.part80
? internal_add_timer
schedule
schedule_preempt
__mutex_lock_slowpath
mutex_lock
sdmmc_request [rtsx_pci_sdmmc]
mmc_start_request [mmc_core]
__mmc_start_req [mmc_core]
mmc_wait_for_cmd [mmc_core]
? mmc_release_host [mmc_core]
mmc_io_rw_direct_host [mmc_core]

I'll try to get a lockdep kernel and text logs later, but perhaps you already
know the issue?

Peter

> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
> b/drivers/mmc/host/rtsx_pci_sdmmc.c index 453e1d4..40695e0 100644
> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> @@ -108,12 +108,10 @@ static void sd_isr_done_transfer(struct
> platform_device *pdev) {
>   struct realtek_pci_sdmmc *host = platform_get_drvdata(pdev);
> 
> - spin_lock(&host->lock);
>   if (host->cmd)
>   tasklet_schedule(&host->cmd_tasklet);
> - if (host->data)
> + else if (host->data)
>   tasklet_schedule(&host->data_tasklet);
> - spin_unlock(&host->lock);
>  }
> 
>  static void sd_request_timeout(unsigned long host_addr)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Peter Wu]

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 only.
> > 
> > The same NULL pointer deref would be visible (slightly different
> > addresses, but the Code lines are equal). With `-host`, the NULL deref
> > with `-cpu host` contains:
> > 
> > [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel 
> > PMU driver.
> > 
> > Full dmesg below.
> > 
> I am confused. Do you see crash now with -cpu SandyBridge and -cpu host, or 
> -cpu host only?

The RAPL crash is seen with both SandyBridge and host, I mentioned SB
because that environment should be more constant than "host" (which
depends on the CPU you have on, well, the host).

Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Peter Wu]

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
> > guest. intel_pmu_cpu_*() -> intel_pmu_lbr_reset() uses rdmsr() /
> > wrmsr(), rather than the safe variants; if KVM does not support the
> > particular MSRs in question, you will see a #GP(0) there. See
> > https://lkml.org/lkml/2014/3/13/453 for a similar bug other PMU code.
> > 
> When kernel is compiled with guest support all rdmsr()/wrmsr() become _safe(),
> so the question for Peter is if his guest kernel has guest support enabled?

Linux guest support (CONFIG_HYPERVISOR_GUEST) was not enabled, see
.config in the first mail[1]. Enabling that option does not change the
situation.

With CONFIG_PARAVIRT and CONFIG_KVM_GUEST enabled, the PMU GPF is gone,
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 only.

The same NULL pointer deref would be visible (slightly different
addresses, but the Code lines are equal). With `-host`, the NULL deref
with `-cpu host` contains:

[0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU 
driver.

Full dmesg below.

Stepping through the debugger (for `-cpu SandyBridge`) showed that the
pmu variable is NULL (in arch/x86/kernel/cpu/perf_event_intel_rapl.c)
Skipping that line (`jump +1` in gdb) allowed Linux to continue
booting without crashing. I have no idea what is going on here,
but hopefully this information helps.

Kind regards,
Peter

 [1]: https://lkml.kernel.org/r/4055058.qLAukpngnj@al

[0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc 
version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #27 Sat Mar 22 10:06:46 CET 2014
[0.00] Command line: console=ttyS0 loglevel=8
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable
[0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000f1b10-0x000f1b1f] mapped at 
[880f1b10]
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x019d1000, 0x019d1fff] PGTABLE
[0.00] BRK [0x019d2000, 0x019d2fff] PGTABLE
[0.00] BRK [0x019d3000, 0x019d3fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x3fc0-0x3fdf]
[0.00]  [mem 0x3fc0-0x3fdf] page 2M
[0.00] init_memory_mapping: [mem 0x3c00-0x3fbf]
[0.00]  [mem 0x3c00-0x3fbf] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x3bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x3bff] page 2M
[0.00] init_memory_mapping: [mem 0x3fe0-0x3fffdfff]
[0.00]  [mem 0x3fe0-0x3fffdfff] page 4k
[0.00] BRK [0x019d4000, 0x019d4fff] PGTABLE
[0.00] ACPI: RSDP 000f19b0 14 (v00 BOCHS )
[0.00] ACPI: RSDT 3ad3 34 (v01 BOCHS  BXPCRSDT 0001 
BXPC 0001)
[0.00] ACPI: FACP 3177 74 (v01 BOCHS  BXPCFACP 

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Peter Wu]

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 
> 3.14.0-rc7-qemu-00059-g08edb33 #14
> [0.024000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [0.024000] task: 88003e05 ti: 88003e054000 task.ti: 
> 88003e054000
> [0.024000] RIP: 0010:[]  [] 
> intel_pmu_lbr_reset+0x2a/0x80
> [0.024000] RSP: :88003e055e78  EFLAGS: 0002
> [0.024000] RAX:  RBX: 0286 RCX: 
> 0680
> [0.024000] RDX:  RSI:  RDI: 
> 
> [0.024000] RBP: 81622120 R08: 88003ffee0e0 R09: 
> 88003e00bf00
> [0.024000] R10:  R11: 0004 R12: 
> 
> [0.024000] R13:  R14:  R15: 
> 
> [0.024000] FS:  () GS:8161e000() 
> knlGS:
> [0.024000] CS:  0010 DS:  ES:  CR0: 80050033
> [0.024000] CR2: 8800019bb000 CR3: 01611000 CR4: 
> 001407b0
> [0.024000] Stack:
> [0.024000]  8101308a 8100e3da 8165ba62 
> 
> [0.024000]  8165b5bd   
> 
> [0.024000]  81655dcd   
> 
> [0.024000] Call Trace:
> [0.024000]  [] ? intel_pmu_cpu_starting+0xa/0x80
> [0.024000]  [] ? x86_pmu_notifier+0x5a/0xc0
> [0.024000]  [] ? init_hw_perf_events+0x4a5/0x4dd
> [0.024000]  [] ? check_bugs+0x42/0x42
> [0.024000]  [] ? do_one_initcall+0x76/0xf9
> [0.024000]  [] ? rest_init+0x70/0x70
> [0.024000]  [] ? kernel_init_freeable+0x57/0x177
> [0.024000]  [] ? rest_init+0x70/0x70
> [0.024000]  [] ? kernel_init+0x5/0xe0
> [0.024000]  [] ? ret_from_fork+0x7a/0xb0
> [0.024000]  [] ? rest_init+0x70/0x70
> [0.024000] Code: 00 8b 15 02 c4 63 00 85 d2 74 69 f6 05 af c3 63 00 3f 75 
> 2d 85 d2 7e 5c 31 f6 31 c0 0f 1f 44 00 00 8b 0d d2 c3 63 00 89 c2 01 f1 <0f> 
> 30 83 c6 01 3b 35 d3 c3 63 00 7c e9 f3 c3 0f 1f 80 00 00 00 
> [0.024000] RIP  [] intel_pmu_lbr_reset+0x2a/0x80
> [0.024000]  RSP 
> [0.024000] ---[ end trace ecbd794f78441b2c ]---
> [0.024002] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b
> 
> 
> It possibly has something to do with the msr write. Reproducable with:
> 
> qemu-system-x86_64 -enable-kvm -cpu host -kernel bzImage -m 1G -serial 
> file:ser.txt
> 
> In the host dmesg, the following is visible when qemu:
> 
> kvm [4939]: vcpu0 unhandled wrmsr: 0x680 data 0
> 
> The full guest dmesg is shown below. The issue occurs also with
> v3.13.6, v3.12.14, v3.10.33 (other versions are not tested).
> 
> QEMU: 1.7.0
> Host kernel: v3.14-rc5
> Guest kernel: v3.14-rc7-59-g08edb33 (.config on the bottom)
> 
> Kind regards,
> Peter
> 
> ### dmesg
> [0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) 
> (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #14 Fri Mar 21 17:30:49 CET 2014
> [0.00] Command line: console=ttyS0 loglevel=8
> [0.00] KERNEL supported cpus:
> [0.00]   Intel GenuineIntel
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable
> [0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved
> [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
> [0.00] BIOS-e820: [mem 0xfffc-0x] reserved
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.4 present.
> [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4
> [0.00] MTRR default type: write-back
> [0.00] MTRR fixed ranges enabled:
> [0.00]   0-9 write-back
> [0.00]   A-B uncachable
> [0.00]   C-F write-protect
> [0.

GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Peter Wu]

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/01/2011
[0.024000] task: 88003e05 ti: 88003e054000 task.ti: 
88003e054000
[0.024000] RIP: 0010:[]  [] 
intel_pmu_lbr_reset+0x2a/0x80
[0.024000] RSP: :88003e055e78  EFLAGS: 0002
[0.024000] RAX:  RBX: 0286 RCX: 0680
[0.024000] RDX:  RSI:  RDI: 
[0.024000] RBP: 81622120 R08: 88003ffee0e0 R09: 88003e00bf00
[0.024000] R10:  R11: 0004 R12: 
[0.024000] R13:  R14:  R15: 
[0.024000] FS:  () GS:8161e000() 
knlGS:
[0.024000] CS:  0010 DS:  ES:  CR0: 80050033
[0.024000] CR2: 8800019bb000 CR3: 01611000 CR4: 001407b0
[0.024000] Stack:
[0.024000]  8101308a 8100e3da 8165ba62 

[0.024000]  8165b5bd   

[0.024000]  81655dcd   

[0.024000] Call Trace:
[0.024000]  [] ? intel_pmu_cpu_starting+0xa/0x80
[0.024000]  [] ? x86_pmu_notifier+0x5a/0xc0
[0.024000]  [] ? init_hw_perf_events+0x4a5/0x4dd
[0.024000]  [] ? check_bugs+0x42/0x42
[0.024000]  [] ? do_one_initcall+0x76/0xf9
[0.024000]  [] ? rest_init+0x70/0x70
[0.024000]  [] ? kernel_init_freeable+0x57/0x177
[0.024000]  [] ? rest_init+0x70/0x70
[0.024000]  [] ? kernel_init+0x5/0xe0
[0.024000]  [] ? ret_from_fork+0x7a/0xb0
[0.024000]  [] ? rest_init+0x70/0x70
[0.024000] Code: 00 8b 15 02 c4 63 00 85 d2 74 69 f6 05 af c3 63 00 3f 75 
2d 85 d2 7e 5c 31 f6 31 c0 0f 1f 44 00 00 8b 0d d2 c3 63 00 89 c2 01 f1 <0f> 30 
83 c6 01 3b 35 d3 c3 63 00 7c e9 f3 c3 0f 1f 80 00 00 00 
[0.024000] RIP  [] intel_pmu_lbr_reset+0x2a/0x80
[0.024000]  RSP 
[0.024000] ---[ end trace ecbd794f78441b2c ]---
[0.024002] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b


It possibly has something to do with the msr write. Reproducable with:

qemu-system-x86_64 -enable-kvm -cpu host -kernel bzImage -m 1G -serial 
file:ser.txt

In the host dmesg, the following is visible when qemu:

kvm [4939]: vcpu0 unhandled wrmsr: 0x680 data 0

The full guest dmesg is shown below. The issue occurs also with
v3.13.6, v3.12.14, v3.10.33 (other versions are not tested).

QEMU: 1.7.0
Host kernel: v3.14-rc5
Guest kernel: v3.14-rc7-59-g08edb33 (.config on the bottom)

Kind regards,
Peter

### dmesg
[0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc 
version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #14 Fri Mar 21 17:30:49 CET 2014
[0.00] Command line: console=ttyS0 loglevel=8
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable
[0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000f1b10-0x000f1b1f] mapped at 
[880f1b10]
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]

Re: [PATCH 0/3] rtlwifi (and staging rtl8821ae) cleanups

[Peter Wu]

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 to take care of rtl8723be.
> > 
> > The other two patches to the staging driver is similar to the rtlwifi
> > changes. I am not sure who to send these two patches to. Greg is the
> > staging maintainer, but John takes wireless patches, so I have included
> > both of you.
> > 
> > All patches are compile-tested on top of v3.14-rc2-938-g67b3bd4.
> > 
> > I also found the following (unrelated to my patches) warning while
> > compiling the staging driver, perhaps it needs a closer look?
> 
> Peter,
> 
> Your Patch 1/3 applies cleanly and I think it is OK, but if you are going to
> do cleanups on the wireless tree, you should be working from the latest
> version of wireless-testing git repo. We are on 3.14-rc7 and there are
> several recent commits that might have conflicted.

The changes are not new, just updated for the latest wireless-next. I did test 
it on wireless-next, apparently it has not synced with Linus' tree yet:

$ git describe wireless-next/master 
v3.14-rc2-938-g67b3bd4
$ git log --oneline -n4 rtlwifi-wireless-next 
cb39071 staging/rtl8821ae: remove unused allow_all_destaddr function
607693e staging/rtl8821ae: avoid accessing RCR directly
7db8deb rtlwifi: remove unused allow_all_destaddr functions
67b3bd4 brcmfmac: fallback to mimo_bw_cap for older firmwares

> As for the changes to staging/rtl8821ae (No. 2 & 3), once Linus starts the
> merge that will precede the release of 3.15-rc2, the entire code for
> rtl8821ae will be replaced. A cleaned-up version was nearly ready for the
> regular wireless tree in time to make 3.15, but it did not get enough
> testing. As a result, that driver will be in testing for one more cycle. By
> 3.16, it should reside in the regular tree and be out of staging.

I must be missing something, since I subscribed to linux-wireless this month, 
I have not seen discussions about a replacement for rtl8821ae. Is this driver 
not published yet?

> Pushing patches that affect both the regular tree and staging is complicated
> and should be avoided whenever possible.

Ok, I kept those in separate patches, but will send different series next time 
if it is preferred.

Thanks,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] staging/rtl8821ae: avoid accessing RCR directly

[Peter Wu]

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(-)

diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
index 5ed7a11..e4dbf05 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
@@ -1633,12 +1633,13 @@ static int _rtl8821ae_set_media_status(struct 
ieee80211_hw *hw,
 void rtl8821ae_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   u32 reg_rcr = rtlpci->receive_config;
+   u32 reg_rcr;
 
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
 
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
+
if (check_bssid == true) {
reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] staging/rtl8821ae: remove unused allow_all_destaddr function

[Peter Wu]

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 --
 drivers/staging/rtl8821ae/rtl8821ae/hw.h |  3 ---
 drivers/staging/rtl8821ae/rtl8821ae/sw.c |  1 -
 drivers/staging/rtl8821ae/wifi.h |  2 --
 4 files changed, 28 deletions(-)

diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
index e4dbf05..8ae4fae 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
@@ -3323,25 +3323,3 @@ void rtl8821ae_suspend(struct ieee80211_hw *hw)
 void rtl8821ae_resume(struct ieee80211_hw *hw)
 {
 }
-
-/* Turn on AAP (RCR:bit 0) for promicuous mode. */
-void rtl8821ae_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg)
-{
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-
-   if (allow_all_da) /* Set BIT0 */
-   rtlpci->receive_config |= RCR_AAP;
-   else /* Clear BIT0 */
-   rtlpci->receive_config &= ~RCR_AAP;
-
-   if(write_into_reg)
-   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
-
-
-   RT_TRACE(COMP_TURBO | COMP_INIT, DBG_LOUD,
-   ("receive_config=0x%08X, write_into_reg=%d\n",
-   rtlpci->receive_config, write_into_reg ));
-}
-
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.h 
b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
index 4fb6bf0..f1d2949 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.h
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.h
@@ -67,9 +67,6 @@ void rtl8821ae_bt_reg_init(struct ieee80211_hw* hw);
 void rtl8821ae_bt_hw_init(struct ieee80211_hw* hw);
 void rtl8821ae_suspend(struct ieee80211_hw *hw);
 void rtl8821ae_resume(struct ieee80211_hw *hw);
-void rtl8821ae_allow_all_destaddr(struct ieee80211_hw *hw,
-   
  bool allow_all_da,
-   
  bool write_into_reg);
 void _rtl8821ae_stop_tx_beacon(struct ieee80211_hw *hw);
 void _rtl8821ae_resume_tx_beacon(struct ieee80211_hw *hw);
 #endif
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/sw.c 
b/drivers/staging/rtl8821ae/rtl8821ae/sw.c
index 85a3474..25a8114 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/sw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/sw.c
@@ -298,7 +298,6 @@ struct rtl_hal_ops rtl8821ae_hal_ops = {
.enable_hw_sec = rtl8821ae_enable_hw_security_config,
.set_key = rtl8821ae_set_key,
.init_sw_leds = rtl8821ae_init_sw_leds,
-   .allow_all_destaddr = rtl8821ae_allow_all_destaddr,
.get_bbreg = rtl8821ae_phy_query_bb_reg,
.set_bbreg = rtl8821ae_phy_set_bb_reg,
.get_rfreg = rtl8821ae_phy_query_rf_reg,
diff --git a/drivers/staging/rtl8821ae/wifi.h b/drivers/staging/rtl8821ae/wifi.h
index cfe88a1..871ff51 100644
--- a/drivers/staging/rtl8821ae/wifi.h
+++ b/drivers/staging/rtl8821ae/wifi.h
@@ -1840,8 +1840,6 @@ struct rtl_hal_ops {
  u32 regaddr, u32 bitmask);
void (*set_rfreg) (struct ieee80211_hw * hw, enum radio_path rfpath,
   u32 regaddr, u32 bitmask, u32 data);
-   void (*allow_all_destaddr)(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg);
void (*linked_set_reg) (struct ieee80211_hw * hw);
void (*check_switch_to_dmdp) (struct ieee80211_hw * hw);
void (*dualmac_easy_concurrent) (struct ieee80211_hw *hw);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] rtlwifi: remove unused allow_all_destaddr functions

[Peter Wu]

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 
---
 - v2: removed functions for rtl8723be too, fix merge conflict due to
   a rename in the context of rtl8723ae.
---
 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/rtlwifi/rtl8192ce/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8192se/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192se/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8723ae/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723be/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8723be/hw.h |  2 --
 drivers/net/wireless/rtlwifi/wifi.h |  2 --
 15 files changed, 118 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index bd2a26b..e655c65 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -2521,23 +2521,3 @@ void rtl88ee_suspend(struct ieee80211_hw *hw)
 void rtl88ee_resume(struct ieee80211_hw *hw)
 {
 }
-
-/* Turn on AAP (RCR:bit 0) for promicuous mode. */
-void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg)
-{
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-
-   if (allow_all_da) /* Set BIT0 */
-   rtlpci->receive_config |= RCR_AAP;
-else /* Clear BIT0 */
-   rtlpci->receive_config &= ~RCR_AAP;
-
-   if (write_into_reg)
-   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
-
-   RT_TRACE(rtlpriv, COMP_TURBO | COMP_INIT, DBG_LOUD,
-"receive_config = 0x%08X, write_into_reg =%d\n",
-rtlpci->receive_config, write_into_reg);
-}
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h 
b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
index b4460a4..1850fde 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
@@ -61,8 +61,6 @@ void rtl8188ee_bt_reg_init(struct ieee80211_hw *hw);
 void rtl8188ee_bt_hw_init(struct ieee80211_hw *hw);
 void rtl88ee_suspend(struct ieee80211_hw *hw);
 void rtl88ee_resume(struct ieee80211_hw *hw);
-void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg);
 void rtl88ee_fw_clk_off_timer_callback(unsigned long data);
 
 #endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
index 347af1e..41de6f3 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
@@ -254,7 +254,6 @@ static struct rtl_hal_ops rtl8188ee_hal_ops = {
.enable_hw_sec = rtl88ee_enable_hw_security_config,
.set_key = rtl88ee_set_key,
.init_sw_leds = rtl88ee_init_sw_leds,
-   .allow_all_destaddr = rtl88ee_allow_all_destaddr,
.get_bbreg = rtl88e_phy_query_bb_reg,
.set_bbreg = rtl88e_phy_set_bb_reg,
.get_rfreg = rtl88e_phy_query_rf_reg,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 4ae51d5..e2ba368 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -2423,24 +2423,3 @@ void rtl92ce_suspend(struct ieee80211_hw *hw)
 void rtl92ce_resume(struct ieee80211_hw *hw)
 {
 }
-
-/* Turn on AAP (RCR:bit 0) for promicuous mode. */
-void rtl92ce_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg)
-{
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-
-   if (allow_all_da) {/* Set BIT0 */
-   rtlpci->receive_config |= RCR_AAP;
-   } else {/* Clear BIT0 */
-   rtlpci->receive_config &= ~RCR_AAP;
-   }
-
-   if (write_into_reg)
-   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
-
-   RT_TRACE(rtlpriv, COMP_TURBO | COMP_INIT, DBG_LOUD,
-"receive_config=0x%08X, write_into_reg=%d\n",
-rtlpci->receive_config, write_into_reg);
-}
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.h 
b/drivers/net/wirel

[PATCH 0/3] rtlwifi (and staging rtl8821ae) cleanups

[Peter Wu]

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 to take care of rtl8723be.

The other two patches to the staging driver is similar to the rtlwifi changes.
I am not sure who to send these two patches to. Greg is the staging maintainer,
but John takes wireless patches, so I have included both of you.

All patches are compile-tested on top of v3.14-rc2-938-g67b3bd4.

I also found the following (unrelated to my patches) warning while compiling the
staging driver, perhaps it needs a closer look?

  CC [M]  drivers/net/wireless/rtlwifi/stats.o
  CC [M]  drivers/staging/rtl8821ae/rtl8821ae/hal_btc.o
drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 
‘rtl8821ae_dm_clear_txpower_tracking_state’:
drivers/staging/rtl8821ae/rtl8821ae/dm.c:487:31: warning: iteration 2u invokes 
undefined behavior [-Waggressive-loop-optimizations]
   rtldm->bb_swing_idx_ofdm[p] = rtldm->default_ofdm_index;
   ^
drivers/staging/rtl8821ae/rtl8821ae/dm.c:485:2: note: containing loop
  for (p = RF90_PATH_A; p < MAX_RF_PATH; ++p) {
  ^
  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/rtl8188ee/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8188ee/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8188ee/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8192se/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192se/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8723ae/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723be/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8723be/hw.h |  2 --
 drivers/net/wireless/rtlwifi/wifi.h |  2 --
 drivers/staging/rtl8821ae/rtl8821ae/hw.c| 27 +++
 drivers/staging/rtl8821ae/rtl8821ae/hw.h|  3 ---
 drivers/staging/rtl8821ae/rtl8821ae/sw.c|  1 -
 drivers/staging/rtl8821ae/wifi.h|  2 --
 19 files changed, 3 insertions(+), 148 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] rtlwifi: remove unused allow_all_destaddr functions

[Peter Wu]

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 the set of
> patches that add the rtl8723be driver, and would cause build errors if the
> merge were fixed. I will hang on to it and apply it later when the
> rtl8723be merge is done.

Fair enough, the next patch will strip even more then :-)

> @John Linville: You should apply #1 and 2 of this series, but skip this one.
> 
> Thanks,
> 
> Larry
> 
> PS: I just noticed the John Linville was not Cc'd on these patches. For
> wireless, such patches should be sent to him with a Cc to the wireless ML.

Ah, I will keep that in mind for future patches. The first reply is now
also sent with John in the recipients list.

Thanks,
Peter

> > ---
> > 
> >   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/rtlwifi/rtl8192ce/hw.c | 21 -
> >   drivers/net/wireless/rtlwifi/rtl8192ce/hw.h |  2 --
> >   drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |  1 -
> >   drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 20 
> >   drivers/net/wireless/rtlwifi/rtl8192se/hw.h |  2 --
> >   drivers/net/wireless/rtlwifi/rtl8192se/sw.c |  1 -
> >   drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 21 -
> >   drivers/net/wireless/rtlwifi/rtl8723ae/hw.h |  2 --
> >   drivers/net/wireless/rtlwifi/rtl8723ae/sw.c |  1 -
> >   drivers/net/wireless/rtlwifi/wifi.h |  2 --
> >   13 files changed, 96 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> > b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c index ce2226c..c0e7f62
> > 100644
> > --- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> > +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
> > @@ -2510,23 +2510,3 @@ void rtl88ee_suspend(struct ieee80211_hw *hw)
> > 
> >   void rtl88ee_resume(struct ieee80211_hw *hw)
> >   {
> >   }
> > 
> > -
> > -/* Turn on AAP (RCR:bit 0) for promicuous mode. */
> > -void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
> > -   bool allow_all_da, bool write_into_reg)
> > -{
> > -   struct rtl_priv *rtlpriv = rtl_priv(hw);
> > -   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
> > -
> > -   if (allow_all_da) /* Set BIT0 */
> > -   rtlpci->receive_config |= RCR_AAP;
> > -else /* Clear BIT0 */
> > -   rtlpci->receive_config &= ~RCR_AAP;
> > -
> > -   if (write_into_reg)
> > -   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
> > -
> > -   RT_TRACE(rtlpriv, COMP_TURBO | COMP_INIT, DBG_LOUD,
> > -"receive_config = 0x%08X, write_into_reg =%d\n",
> > -rtlpci->receive_config, write_into_reg);
> > -}
> > diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
> > b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h index b4460a4..1850fde
> > 100644
> > --- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
> > +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
> > @@ -61,8 +61,6 @@ void rtl8188ee_bt_reg_init(struct ieee80211_hw *hw);
> > 
> >   void rtl8188ee_bt_hw_init(struct ieee80211_hw *hw);
> >   void rtl88ee_suspend(struct ieee80211_hw *hw);
> >   void rtl88ee_resume(struct ieee80211_hw *hw);
> > 
> > -void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
> > -   bool allow_all_da, bool write_into_reg);
> > 
> >   void rtl88ee_fw_clk_off_timer_callback(unsigned long data);
> >   
> >   #endif
> > 
> > diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> > b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c index 347af1e..41de6f3
> > 100644
> > --- a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> > +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
> > @@ -254,7 +254,6 @@ static struct rtl_hal_ops rtl8188ee_hal_ops = {
> > 
> > .enable_hw_sec = rtl88ee_enable_hw_security_config,
> > .set_key = rtl88ee_set_key,
> > .init_sw_leds = rtl88ee_init_sw_leds,
> > 
> > -   .allow_all_destaddr = rtl88ee_allow_all_destaddr,
> > 
> > .get_bbreg = rtl88e_phy_query_bb_reg,
> > .set_bbreg = rtl88e_phy_set_bb_reg,
> > .get_rfreg = rtl88e_phy_query_rf_reg,
> > 
> &g

Re: [PATCH 1/3] rtlwifi: avoid accessing RCR directly

[Peter Wu]

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 and mac->rx_conf for
> > USB).
> > 
> > There is no functional change for cases where receive_config was
> > accessed 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 
> 
> Acked-by: Larry Finger 

TLD is missing ;)

> With this change it will not take much work to move all the
> *_set_check_bssid  functions into a common version in rtlwifi. But that
> will have to wait as I have one new driver submitted, but not merged, and
> two others that are not quite ready for submission.

There are three variants of the set_check_bssid functions:
- four that modify the beacon filter (through _rtl*_set_bcn_ctrl_reg)
- one (rtl8192se) that does not modify the beacon filter and writes
  less bits (just RCR_BSSID instead of RCR_BSSID_{DATA,BCN})
- one (rtl8192cu) that modifies the beacon filter, and depending on
  the chip version, sets the same bits as rtl8192se, or the other four.

I was not sure where to move the set_bcn_ctrl_reg functions, these
depend on a value from rtl*/reg.h. Perhaps the [gs]et_hw_reg functions
can be extended with these registers?

Thanks,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] rtlwifi promiscious mode fix and cleanup

[Peter Wu]

Hi,

While investigating bug 60713[1] which is about the inability to connect
with RTL8192CE hardware, I noticed that the monitor mode only shows
broadcast and multicast frames. The cause is described next.

`rtlpci->receive_config` seems to contain the current value of REG_RCR.
It gets initialized in rtl*_init_sw_vars. It is returned by
rtl*_get_hw_reg and set by rtl*_set_hw_reg (after writing to REG_RCR).

`mac->rx_conf` is initialized in rtl_init_rx_config. For PCIe drivers,
it gets inited from `receive_config` via get_hw_reg (one of the
functions from the previous section).

When monitor mode is enabled with otherbss set, rtl_op_configure_filter
is called. This has a problem:

(1) The rtl_op_configure_filter function only sets mac->rx_conf.
(2) rx_conf is only written to register REG_RCR by rtl8192cu and besides
that driver, it is only read by rtl_init_rx_config in base.c.

Patch 2/3 fixes the above issue. 1/2 makes accessing RCR more consistent
and 3/3 removes unused functions (yay, less code!). Similar
modifications (3 and probably 1) need to be done for staging.

I have tested these patches on top of v3.14-rc2-267-g9398a10, but it
unfortunately does not improve the connectivity problem. It got even
stranger, when I run `iw wlan0 set monitor fcsfail`, I do not see a
"Enable receive FCS error frame" message with debug=5. Instead I see
"Enable receive control frame". More testing will be done later this
day. For example, only the first and second EAPOL frame of a second test
device got captured, others got lost somehow. Hopefully it is not a
memory corruption issue somewhere.

Related question for a Realtek engineer (or someone with access to the
specs): the rx_ctrl_filter and rx_data_filter fields are only *read* in
the rtl8192cu driver. Besides that they are unused. Can this be removed?
Otherwise, what about moving them to rtl_init_rx_config() and updating
the *_get_hw_reg() functions to ignore/process the vars? After doing so,
_update_mac_setting can be removed from rtl8192cu/hw.c.

Regards,
Peter

 [1]: https://bugzilla.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/wireless/rtlwifi/rtl8188ee/hw.c | 25 ++
 drivers/net/wireless/rtlwifi/rtl8188ee/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8188ee/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 25 ++
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |  4 ++-
 drivers/net/wireless/rtlwifi/rtl8192de/hw.c |  6 ++--
 drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 25 ++
 drivers/net/wireless/rtlwifi/rtl8192se/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192se/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 26 ++-
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8723ae/sw.c |  1 -
 drivers/net/wireless/rtlwifi/wifi.h |  2 --
 16 files changed, 49 insertions(+), 128 deletions(-)

-- 
1.8.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] rtlwifi: properly apply filter flags

[Peter Wu]

commit 0baa0fd76f3f5a134461d6cf30294f6bb1bb824c
("rtlwifi: Convert core routines for addition of rtl8192se and
rtl8192de") removed setting HW_VAR_RCR, HW_VAR_MGT_FILTER and
HW_VAR_CTRL_FILTER. The last two are probably done because some hardware
does not support them. The first is probably a mistake. This patch adds
the missing set_hw_reg call.

For PCI support, rx_conf is not touched directly. Instead, get_hw_reg is
used to abstract between receive_config (for PCI) and rx_conf (for USB).

This was tested on a 10ec:8176 Realtek RTL8188CE (according to the
label on the mini-PCIe card). 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 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/core.c 
b/drivers/net/wireless/rtlwifi/core.c
index 2d337a0..6df4df0 100644
--- a/drivers/net/wireless/rtlwifi/core.c
+++ b/drivers/net/wireless/rtlwifi/core.c
@@ -475,20 +475,40 @@ static void rtl_op_configure_filter(struct ieee80211_hw 
*hw,
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+   u32 rx_conf;
 
*new_flags &= RTL_SUPPORTED_FILTERS;
if (!changed_flags)
return;
 
+   /* if ssid not set to hw don't check bssid
+* here just used for linked scanning, & linked
+* and nolink check bssid is set in set network_type */
+   if ((changed_flags & FIF_BCN_PRBRESP_PROMISC) &&
+   (mac->link_state >= MAC80211_LINKED)) {
+   if (mac->opmode != NL80211_IFTYPE_AP &&
+   mac->opmode != NL80211_IFTYPE_MESH_POINT) {
+   if (*new_flags & FIF_BCN_PRBRESP_PROMISC) {
+   rtlpriv->cfg->ops->set_chk_bssid(hw, false);
+   } else {
+   rtlpriv->cfg->ops->set_chk_bssid(hw, true);
+   }
+   }
+   }
+
+   /* must be called after set_chk_bssid since that function modifies the
+* RCR register too. */
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(&rx_conf));
+
/*TODO: we disable broadcase now, so enable here */
if (changed_flags & FIF_ALLMULTI) {
if (*new_flags & FIF_ALLMULTI) {
-   mac->rx_conf |= rtlpriv->cfg->maps[MAC_RCR_AM] |
+   rx_conf |= rtlpriv->cfg->maps[MAC_RCR_AM] |
rtlpriv->cfg->maps[MAC_RCR_AB];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
 "Enable receive multicast frame\n");
} else {
-   mac->rx_conf &= ~(rtlpriv->cfg->maps[MAC_RCR_AM] |
+   rx_conf &= ~(rtlpriv->cfg->maps[MAC_RCR_AM] |
  rtlpriv->cfg->maps[MAC_RCR_AB]);
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
 "Disable receive multicast frame\n");
@@ -497,39 +517,25 @@ static void rtl_op_configure_filter(struct ieee80211_hw 
*hw,
 
if (changed_flags & FIF_FCSFAIL) {
if (*new_flags & FIF_FCSFAIL) {
-   mac->rx_conf |= rtlpriv->cfg->maps[MAC_RCR_ACRC32];
+   rx_conf |= rtlpriv->cfg->maps[MAC_RCR_ACRC32];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
 "Enable receive FCS error frame\n");
} else {
-   mac->rx_conf &= ~rtlpriv->cfg->maps[MAC_RCR_ACRC32];
+   rx_conf &= ~rtlpriv->cfg->maps[MAC_RCR_ACRC32];
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
 "Disable receive FCS error frame\n");
}
}
 
-   /* if ssid not set to hw don't check bssid
-* here just used for linked scanning, & linked
-* and nolink check bssid is set in set network_type */
-   if ((changed_flags & FIF_BCN_PRBRESP_PROMISC) &&
-   (mac->link_state >= MAC80211_LINKED)) {
-   if (mac->opmode != NL80211_IFTYPE_AP &&
-   mac->opmode != NL80211_IFTYPE_MESH_POINT) {
-   if (*new_flags & FIF_BCN_PRBRESP_PROMISC) {
-   rtlpriv->cfg->ops->set_chk_bssid(hw, false);
-   } else {
-   rtlpriv->cfg->ops->set_chk_bssid(hw, true);
-   }
- 

[PATCH 3/3] rtlwifi: remove unused allow_all_destaddr functions

[Peter Wu]

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/rtlwifi/rtl8192ce/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192ce/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 20 
 drivers/net/wireless/rtlwifi/rtl8192se/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8192se/sw.c |  1 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 21 -
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.h |  2 --
 drivers/net/wireless/rtlwifi/rtl8723ae/sw.c |  1 -
 drivers/net/wireless/rtlwifi/wifi.h |  2 --
 13 files changed, 96 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index ce2226c..c0e7f62 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -2510,23 +2510,3 @@ void rtl88ee_suspend(struct ieee80211_hw *hw)
 void rtl88ee_resume(struct ieee80211_hw *hw)
 {
 }
-
-/* Turn on AAP (RCR:bit 0) for promicuous mode. */
-void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg)
-{
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-
-   if (allow_all_da) /* Set BIT0 */
-   rtlpci->receive_config |= RCR_AAP;
-else /* Clear BIT0 */
-   rtlpci->receive_config &= ~RCR_AAP;
-
-   if (write_into_reg)
-   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
-
-   RT_TRACE(rtlpriv, COMP_TURBO | COMP_INIT, DBG_LOUD,
-"receive_config = 0x%08X, write_into_reg =%d\n",
-rtlpci->receive_config, write_into_reg);
-}
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h 
b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
index b4460a4..1850fde 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.h
@@ -61,8 +61,6 @@ void rtl8188ee_bt_reg_init(struct ieee80211_hw *hw);
 void rtl8188ee_bt_hw_init(struct ieee80211_hw *hw);
 void rtl88ee_suspend(struct ieee80211_hw *hw);
 void rtl88ee_resume(struct ieee80211_hw *hw);
-void rtl88ee_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg);
 void rtl88ee_fw_clk_off_timer_callback(unsigned long data);
 
 #endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
index 347af1e..41de6f3 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/sw.c
@@ -254,7 +254,6 @@ static struct rtl_hal_ops rtl8188ee_hal_ops = {
.enable_hw_sec = rtl88ee_enable_hw_security_config,
.set_key = rtl88ee_set_key,
.init_sw_leds = rtl88ee_init_sw_leds,
-   .allow_all_destaddr = rtl88ee_allow_all_destaddr,
.get_bbreg = rtl88e_phy_query_bb_reg,
.set_bbreg = rtl88e_phy_set_bb_reg,
.get_rfreg = rtl88e_phy_query_rf_reg,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 25e178c..8b3134a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -2407,24 +2407,3 @@ void rtl92ce_suspend(struct ieee80211_hw *hw)
 void rtl92ce_resume(struct ieee80211_hw *hw)
 {
 }
-
-/* Turn on AAP (RCR:bit 0) for promicuous mode. */
-void rtl92ce_allow_all_destaddr(struct ieee80211_hw *hw,
-   bool allow_all_da, bool write_into_reg)
-{
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-
-   if (allow_all_da) {/* Set BIT0 */
-   rtlpci->receive_config |= RCR_AAP;
-   } else {/* Clear BIT0 */
-   rtlpci->receive_config &= ~RCR_AAP;
-   }
-
-   if (write_into_reg)
-   rtl_write_dword(rtlpriv, REG_RCR, rtlpci->receive_config);
-
-   RT_TRACE(rtlpriv, COMP_TURBO | COMP_INIT, DBG_LOUD,
-"receive_config=0x%08X, write_into_reg=%d\n",
-rtlpci->receive_config, write_into_reg);
-}
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.h 
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.h
index 2d063b0..5533070 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.h
@@ -76,7 +76,5 @@ void rtl8192ce_bt_reg_init(struct ieee80211_hw *hw);
 void rtl8192ce_bt_hw_init(struct ieee80211_hw *hw);
 void rtl92ce_suspend(struct ieee80211_hw *hw);
 void rtl92ce_resume(struct ieee80211_hw *hw);
-void rtl92ce_allow_all_destaddr(struct ieee80211_hw *hw,
-  

[PATCH 1/3] rtlwifi: avoid accessing RCR directly

[Peter Wu]

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 and mac->rx_conf for
USB).

There is no functional change for cases where receive_config was
accessed 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/rtl8188ee/hw.c | 5 +++--
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 4 +++-
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 4 +++-
 drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 6 --
 drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 5 +++--
 drivers/net/wireless/rtlwifi/rtl8723ae/hw.c | 5 +++--
 6 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index e06971b..ce2226c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -1235,12 +1235,13 @@ static int _rtl88ee_set_media_status(struct 
ieee80211_hw *hw,
 void rtl88ee_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   u32 reg_rcr = rtlpci->receive_config;
+   u32 reg_rcr;
 
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
 
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
+
if (check_bssid == true) {
reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index a82b30a..25e178c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1200,11 +1200,13 @@ static int _rtl92ce_set_media_status(struct 
ieee80211_hw *hw,
 void rtl92ce_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+   u32 reg_rcr;
 
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
 
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
+
if (check_bssid) {
reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index 468bf73..49ad106 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1379,11 +1379,13 @@ void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, 
bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
-   u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+   u32 reg_rcr;
 
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
 
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
+
if (check_bssid) {
u8 tmp;
if (IS_NORMAL_CHIP(rtlhal->version)) {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
index c4a7db9..c16aa6b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
@@ -1138,11 +1138,13 @@ static int _rtl92de_set_media_status(struct 
ieee80211_hw *hw,
 void rtl92de_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   u32 reg_rcr = rtlpci->receive_config;
+   u32 reg_rcr;
 
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
+
+   rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
+
if (check_bssid) {
reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR, (u8 *)(®_rcr));
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
index 4f46178..5aa39ef 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
@@ -1135,12 +1135,13 @@ void rtl92se_set_mac_addr(struct rtl_io *io, const u8 
*addr)
 void rtl92se_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   u32 reg_rcr = rtlpci->receive_config;
+   u32 reg_rcr;
 
if (rtlpriv-

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > the ACPI hotplug code that overlooks this and removes the device 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 the ACPI spec.

Tested-by: Peter Wu 

This works, the devices are not lost anymore after resume. dmesg
mentions the 04:00.* devices at resume compared to the unpatched kernel:

[   42.650721] PM: Finishing wakeup.
[   42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   42.650874] iwlwifi :05:00.0: no hotplug settings from platform
[   42.650722] Restarting tasks ... done.
[   42.650985] video LNXVIDEO:00: Restoring backlight state
[   42.650988] video LNXVIDEO:01: Restoring backlight state
[   43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[   43.128401] jme :04:00.5: irq 50 for MSI/MSI-X
[   43.153005] jme :04:00.5 eth0: Link is down
[   43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[   43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[   43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[   43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP01
[   43.276257] xhci_hcd :02:00.0: no hotplug settings from platform
[   43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[   43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP02
[   43.276355] sdhci-pci :04:00.0: no hotplug settings from platform
[   43.276368] pci :04:00.2: no hotplug settings from platform
[   43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform
[   43.276393] jme :04:00.5: no hotplug settings from platform
[   43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   43.276491] iwlwifi :05:00.0: no hotplug settings from platform
[   43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

Rafael, do you want me to test the other patch as well?

Peter

> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86
> 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
> *slot) return (unsigned int)sta;
>  }
> 
> +static inline bool device_sta_valid(unsigned long long sta)
> +{
> + /*
> +  * ACPI spec says that _STA may return bit 0 clear with bit 8 set
> +  * if the device is valid but does not require device driver to be
> +  * loaded (chapter 6.3.7).
> +  */
> + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
> + return (sta & mask) == mask;
> +}
> +
>  /**
>   * trim_stale_devices - remove PCI devices that are not responding.
>   * @dev: PCI device to start walking the hierarchy from.
> @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
>   unsigned long long sta;
> 
>   status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
> - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
> + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta))
> 
>   || acpiphp_no_hotplug(handle);
> 
>   }
>   if (!alive) {
> @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
> *bridge) mutex_lock(&slot->crit_sect);
>   if (slot_no_hotplug(slot)) {
>   ; /* do nothing */
> - } else if (get_slot_status(slot) == ACPI_STA_ALL) {
> + } else if (device_sta_valid(get_slot_status(slot))) {
>   /* remove stale devices if any */
>   list_for_each_entry_safe_reverse(dev, tmp,
>&bus->devices, 
> bus_list)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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: Check for new devices on enabled slots
> 
> This one, or another one in that series.  I rather suspect
> 
> ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious
> notifies"
> 
> from Mika, but it really doesn't matter.
> 
> Can you please check the patch below (it is on top of 3.14-rc1, but I think
> it'll still apply to 3.13) and report back?

I applied the following patch:

--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018 
+0100
+++ drivers/pci/hotplug/acpiphp_glue.c  2014-02-10 01:48:59.634124004 +0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot->bus;
struct acpiphp_func *func;
-   int max, pass;
+   int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
 
-   acpiphp_rescan_slot(slot);
+   nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, &bus->devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev->subordinate,
   &add_list);
}
+   bridges_scanned++;
}
}
}
+   /* Nothing more to do here if there are no new devices on this bus. */
+   if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
+   pr_debug("No more new devices on this bus.\n");
+   return;
+   }
+
__pci_bus_assign_resources(bus, &add_list, NULL);
 
acpiphp_sanitize_bus(bus);

Unfortunately, the adapter still vanishes. dmesg is below this message.

Peter

[   44.558995] CPU3 is up
[   44.561438] ACPI: Waking up from system sleep state S3
[   45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[   45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[   45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[   45.361012] PM: noirq resume of devices complete after 133.354 msecs
[   45.361292] PM: early resume of devices complete after 0.233 msecs
[   45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[   45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[   45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[   45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[   45.701385] ata1.00: configured for UDMA/133
[   45.701503] sd 0:0:0:0: [sda] Starting disk
[   45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   45.872011] ata2.00: configured for UDMA/100
[   46.791141] PM: resume of devices complete after 1430.658 msecs
[   46.791560] PM: Finishing wakeup.
[   46.791565] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   46.791642] acpiphp_glue: No more new devices on this bus.
[   46.791571] Restarting tasks ... done.
[   46.793204] video LNXVIDEO:00: Restoring backlight state
[   46.793211] video LNXVIDEO:01: Restoring backlight state
[   47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[   47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[   47.276949] jme :04:00.5 eth0: Link is down
[   47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[   47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[   47.393492] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[   47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP01
[   47.393517] acpiphp_glue: No more new devices on this bus.
[   47.393525] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[   47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP02
[   47.398977] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   47.463615] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   47.463620] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   47.463685] acpiphp_glue: No more new devices on this bus.

After the last message, NetworkManager loses the interface within a second.
The next following messages follow two seconds later and are unrelated
(those are about wireless connectivity).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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() calls in hotplug_notify() with pr_info() and
> see if you get any events from there.

I could not find a hotplug_notify function in the kernel tree, but I
have dyndbg enabled. Booting with `pci_hotplug.debug=Y
pci_hotplug.debug_acpi=Y pci_hotplug.dyndbg acpiphp.dyndbg` gives me
only a few acpiphp_glue messages. After resume:

[   55.492261] CPU3 is up
[   55.494710] ACPI: Waking up from system sleep state S3
[   56.187298] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[   56.213939] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[   56.240614] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[   56.294230] PM: noirq resume of devices complete after 133.375 msecs
[   56.294507] PM: early resume of devices complete after 0.231 msecs
[   56.294798] pcieport :00:1c.1: System wakeup disabled by ACPI
[   56.296628] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[   56.404258] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[   56.627043] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   56.627929] ata1.00: configured for UDMA/133
[   56.628044] sd 0:0:0:0: [sda] Starting disk
[   56.633730] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   56.640403] ata5: SATA link down (SStatus 0 SControl 300)
[   56.802771] ata2.00: configured for UDMA/100
[   57.737542] PM: resume of devices complete after 1443.847 msecs
[   57.737951] PM: Finishing wakeup.
[   57.737957] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   57.737960] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   57.738080] iwlwifi :05:00.0: no hotplug settings from platform
[   57.737963] Restarting tasks ... done.
[   57.740480] video LNXVIDEO:00: Restoring backlight state
[   57.740487] video LNXVIDEO:01: Restoring backlight state
[   58.203311] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[   58.204080] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[   58.204083] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP01
[   58.204121] xhci_hcd :02:00.0: no hotplug settings from platform
[   58.204132] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[   58.204134] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP02
[   58.209339] jme :04:00.5: irq 50 for MSI/MSI-X
[   58.233503] jme :04:00.5 eth0: Link is down
[   58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   58.235113] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[   58.242131] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[   58.346311] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   58.392764] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[   58.392766] acpiphp_glue: hotplug_event: re-enumerating slots under 
\_SB_.PCI0.RP03
[   58.392874] iwlwifi :05:00.0: no hotplug settings from platform

RP02 is the ACPI Device for 00:1c.1 [1].

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: Check for new devices on enabled slots

The current implementation of acpiphp_check_bridge() is pretty dumb:
 - It enables a slot if it's not enabled and the slot status is
   ACPI_STA_ALL.
 - It disables a slot if it's enabled and the slot status is not
   ACPI_STA_ALL.

This behavior is not sufficient to handle the Thunderbolt daisy
chaining case properly, however, because in that case the bus
behind the already enabled slot needs to be rescanned for new
devices.

For this reason, modify acpiphp_check_bridge() so that slots are
disabled and stopped if they are not in the ACPI_STA_ALL state.

For slots in the ACPI_STA_ALL state, devices behind them that don't
respond are trimmed using a new function, trim_stale_devices(),
introduced specifically for this purpose.  That function walks
the given bus and checks each device on it.  If the device doesn't
respond, it is assumed to be gone and is removed.

Once all of the stale devices directy behind the slot have been
removed, acpiphp_check_bridge() will start looking for new devices
that might have appeared on the given bus.  It will do that even if
the slot is already enabled (SLOT_ENABLED is set for it).

In addition to that, make the bus check notification ignore
SLOT_ENABLED and go for enable_device() directly if bridge is NULL,
so that devices behind the slot are re-enumerated in that case too.

This change is based on earlier patches from Kirill A Shute

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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 failed: Connection timed out
> 
> So I only got the unpriviledge output.

This seems to be an issue of the rtsx driver / hardware, I also see it on
a small Shuttle computer that runs at work. (off-topic lspci post:)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 
[10ec:5289] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:5289]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  Some complementary lines from my journal:
> 
> kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> kernel: r8169 :03:00.2: can't disable ASPM; OS doesn't have ASPM control
> kernel: pcieport :00:1c.3: driver skip pci_set_master, fix it! kernel:
> r8169 :03:00.2: irq 44 for MSI/MSI-X
> kernel: r8169 :03:00.2 eth0: RTL8411 at 0xc90016ed4000,
> 00:90:f5:d7:34:53, XID 08800800 IRQ 44
> kernel: r8169 :03:00.2 eth0: jumbo features [frames: 9200 bytes, tx
> checksumming: ko]
> kernel: rtsx_pci :03:00.0: irq 45 for MSI/MSI-X
> kernel: rtsx_pci :03:00.0: rtsx_pci_acquire_irq: pcr->msi_en = 1,
> pci->irq = 45
> ...
> 
> And one I thought of interest:
> 
> kernel: rtsx_pci :03:00.0: vpd r/w failed.  This is likely a
> firmware bug on this device.  Contact the card vendor for a firmware update.

I think I have seen such an error before, but I cannot find it in the logs
that were obtained a while ago. Failure to read VPD should not cause issues.

> That came three times before suspend.
> 
> Only two lines about hotplug, none special.

I think this is relevant. See also my test with 3.13.2 and different
kernel configs[1]. A workaround that triggers a scan was also posted[2].

Peter

 [1]: http://lkml.org/lkml/2014/2/8/264
 [2]: http://lkml.org/lkml/2014/2/7/809

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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 released by Greg, without and distro
> "improvements") have it too?

It was a regression from 3.11.x to 3.12 (and it is still broken with 3.13).
Due to some mistakes from my side, I have tested more configs:

(based on Arch Linux 3.13.1 x86_64 config)
(a) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works.
(b) 3.13.2 with CONFIG_HOTPLUG_PCI=y and CONFIG_HOTPLUG_PCI_ACPI=y is broken.
(c) 3.13.2 with CONFIG_HOTPLUG_PCI=n still works.
(my stripped config)
(d) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works.

With CONFIG_HOTPLUG_PCI_ACPI=y, the only difference in dmesg is:

(during boot)
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
(after resume)
iwlwifi :05:00.0: no hotplug settings from platform
xhci_hcd :02:00.0: no hotplug settings from platform
 (here, NetworkManager complains that a device has gone)
iwlwifi :05:00.0: no hotplug settings from platform

Of course, with config (b), the ethernet adapter vanishes while it is still
present with configs (a), (c) and (d).

Time to do a bisect?

Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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: irq 50 for MSI/MSI-X
> > [   49.671645] jme :04:00.5 eth0: Link is down
> 
> Well, this means that Ethernet device is present after the resume.

Right, but it is gone when I check it (lspci). Here is the original
journal with dates and machine name stripped from the left (2 seconds):

systemd[1]: Stopping Sleep.
systemd[1]: Stopped target Sleep.
systemd[1]: Starting Suspend.
systemd[1]: Reached target Suspend.
systemd-logind[284]: Operation finished.
NetworkManager[276]:  wake requested (sleeping: yes  enabled: yes)
NetworkManager[276]:  waking up and re-enabling...
NetworkManager[276]:  WWAN now enabled by management service
NetworkManager[276]:  (eth0): device state change: unmanaged -> 
unavailable (reason 'managed') [10 20 2]
NetworkManager[276]:  (eth0): bringing up device.
kernel: ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
kernel: jme :04:00.5: irq 50 for MSI/MSI-X
dbus[285]: [system] Successfully activated service 'org.freedesktop.UPower'
systemd[1]: Started Daemon for power management.
NetworkManager[276]:  (eth0): preparing device.
NetworkManager[276]:  (eth0): deactivating device (reason 'managed') [2]
NetworkManager[276]:  NetworkManager state is now DISCONNECTED
NetworkManager[276]:  (wlan0): device state change: unmanaged -> 
unavailable (reason 'managed') [10 20 2]
NetworkManager[276]:  (wlan0): bringing up device.
kernel: jme :04:00.5 eth0: Link is down
kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
kernel: iwlwifi :05:00.0: L1 Enabled; Disabling L0S
kernel: iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
NetworkManager[276]:  (wlan0): preparing device.
NetworkManager[276]:  (wlan0): deactivating device (reason 'managed') [2]
kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
NetworkManager[276]:  (wlan0) supports 5 scan SSIDs
NetworkManager[276]:  (wlan0): supplicant interface state: starting -> 
ready
NetworkManager[276]:  (wlan0): device state change: unavailable -> 
disconnected (reason 'supplicant-available') [20 30 42]
NetworkManager[276]:  Trying to remove a non-existant call id.
NetworkManager[276]:  (wlan0): supplicant interface state: ready -> 
disconnected
NetworkManager[276]:  (wlan0) supports 5 scan SSIDs
kernel: xhci_hcd :02:00.0: no hotplug settings from platform
kernel: iwlwifi :05:00.0: no hotplug settings from platform
NetworkManager[276]:  (eth0): device state change: unavailable -> 
unmanaged (reason 'removed') [20 10 36]
NetworkManager[276]:  (eth0): cleaning up...
NetworkManager[276]:  (2) failed to find interface name for index
NetworkManager[276]: (nm-system.c:766):nm_system_iface_get_flags: runtime check 
failed: (iface != NULL)
NetworkManager[276]:  [1391703079.229919] [nm-system.c:768] 
nm_system_iface_get_flags(): (unknown): failed to get interface link object

> > [   49.671717] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> > [   49.674119] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> > [   49.681037] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
> > [   49.778035] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > [   49.806241] xhci_hcd :02:00.0: no hotplug settings from platform
> > [   49.859417] iwlwifi :05:00.0: no hotplug settings from platform
> > [   56.264694] wlan0: authenticate with [STRIPPED]
> > [   56.277969] wlan0: send auth to [STRIPPED] (try 1/3)
> > [   56.282076] wlan0: authenticated
> > [   56.283879] wlan0: associate with [STRIPPED] (try 1/3)
> > [   56.297196] wlan0: RX AssocResp from [STRIPPED] (capab=0x411 status=0
> > aid=6) [   56.303746] wlan0: associated
> > [   56.303826] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> 
> Can you check the lspci differences between before/after the suspend-resume
> cycle?

See below. The MAbort+ looks suspicious. 00:1c.1 is the parent of the
devices on bus 4.

(`lspci -nnvt` differences:)

- +-1c.1-[04]--+-00.0  JMicron Technology Corp. SD/MMC Host 
Controller [197b:2382]
- |+-00.2  JMicron Technology Corp. Standard SD Host 
Controller [197b:2381]
- |+-00.3  JMicron Technology Corp. MS Host Controller 
[197b:2383]
- |\-00.5  JMicron Technology Corp. JMC250 PCI Express 
Gigabit Ethernet Controller [197b:0250]
+ +-1c.1-[04]--


--- lspci-nnvvv.txt 2014-02-06 17:11:02.867233563 +0100
+++ lspci-nnvvv2.txt2014-02-06 17:11:22.603425311 +0100
@@ -86,17 +86,17 @@
 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 2 [8086:3b44] (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisIN

Re: 3.12: ethernet controller missing after resuming from suspend to RAM

[Peter Wu]

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 after resume are:
> $ sudo lspci -v
[..]
> 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)
> Subsystem: CLEVO/KAPOK Computer Device 0540
> Flags: bus master, fast devsel, latency 0, IRQ 45
> I/O ports at e000 [size=256]
> Memory at f0a04000 (64-bit, prefetchable) [size=4K]
> Memory at f0a0 (64-bit, prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 01
> Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
> Capabilities: [d0] Vital Product Data
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00
> Kernel driver in use: r8169
> Kernel modules: r8169

I also have an affected laptop where the network and MMC controller
vanishes on resume. The laptop is also from Clevo, but a different
model: Clevo B7130. I had no issues with my custom kernel
configuration (latest version that I tested was 3.13.1), but at least
the stock Arch kernels from 3.12.2 up to 3.12.6 and 3.13.1 are
affected by this issue.

Reproduce with:

 1. Boot system.
 2. lspci -nnvt > lspci-nnvt.txt
 3. Suspend system (lid close)
 4. lspci -nnvt > lspci-nnvt2.txt
 5. Observe missing network controller (see diff below).

--- boot-3.13.1/lspci-nnvt.txt  2014-02-06 17:11:07.070625446 +0100
+++ boot-3.13.1/lspci-nnvt2.txt 2014-02-06 17:11:19.843386871 +0100
@@ -11,10 +11,7 @@
  +-1a.0  Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller [8086:3b3c]
  +-1b.0  Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio [8086:3b56]
  +-1c.0-[02-03]00.0  NEC Corporation uPD720200 USB 3.0 Host 
Controller [1033:0194]
- +-1c.1-[04]--+-00.0  JMicron Technology Corp. SD/MMC Host 
Controller [197b:2382]
- |+-00.2  JMicron Technology Corp. Standard SD Host 
Controller [197b:2381]
- |+-00.3  JMicron Technology Corp. MS Host Controller 
[197b:2383]
- |\-00.5  JMicron Technology Corp. JMC250 PCI Express 
Gigabit Ethernet Controller [197b:0250]
+ +-1c.1-[04]--
  +-1c.2-[05]00.0  Intel Corporation Centrino Advanced-N 6200 
[8086:422c]
  +-1d.0  Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller [8086:3b34]
  +-1e.0-[06]--

The only difference now is the kernel config. I guess that it comes
from CONFIG_HOTPLUG_PCI. In my non-broken config, it's unset. The
Arch kernel sets CONFIG_HOTPLUG_PCI=y (and also
CONFIG_HOTPLUG_PCI_ACPI=y).

That guess is based on the additional messages I see with the broken config:

[1.033628] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[1.033642] pciehp: PCI Express Hot Plug Controller Driver version: 0.4  

 
...
[  102.704377] iwlwifi :05:00.0: no hotplug settings from platform
[  103.170193] xhci_hcd :02:00.0: no hotplug settings from platform
[  103.229008] iwlwifi :05:00.0: no hotplug settings from platform

Before I start bisecting, do you have any ideas to debug this?

The stock config of Arch Linux kernel 3.13.1-2-ARCH can be found on:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linux&id=0ea780ba731bd214db3007f57f54a3fad709a078

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How should dev_[gs]et_drvdata be used?

[Peter Wu]

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; 
> > klist_init(&dev->p->klist_children, klist_children_get,
> >klist_children_put);
> > INIT_LIST_HEAD(&dev->p->deferred_probe);
> > return 0;
> > }
> > 
> > and if it doesn't, then I must be missing something in this non-obvious
> > code. I scanned the interwebs and Documentation/, but could not really
> > find a great example on how this is supposed to work. The dev_set_drvdata
> > function existed since Linus moved to git.
> 
> You're missing that device_private_init() is only called if (!dev->p).
> It's a one time initializer and after that we only set the driver_data.

Yes I am aware of that, the question is about the memory that got allocated
in vfio_group_create_device().

I think I have found the answer. The "dev" device is passed from the PCI
layer, that will probably take care of freeing the resources when the
device is gone. Is this view correct?

Thanks for your replies!

Peter

> > > Also, the code referenced is kfree'ing a struct vfio_device, not the
> > > struct device.  VFIO uses the drvdata to provide a back pointer to the
> > > vfio specific structure, which also includes a pointer to the struct
> > > device.  We obviously want to clear drvdata when the vfio specific
> > > structure is being released.
> > 
> > Ah, I see. "device->dev" is not freed, but "device". And the data is
> > cleared for "device->dev". Thanks for correcting.
> > 
> > Clear examples of how to use dev_{s,g}et_drvdata correctly in i2c is
> > still wanted. I stepped in it yesterday, i2c seems to have its own
> > way to register new devices. More specifically, how can the memory
> > associated with dev_set_drvdata be free'd on error paths if the
> > device is not registered with device_register (as is done in the
> > probe function of the i801 i2c driver)?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How should dev_[gs]et_drvdata be used?

[Peter Wu]

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 of setting to NULL on error.
> > Then device_unregister frees the memory, right?
> > 
> > Now, what if the dev_set_drvdata (or aliases such as pci_set_drvdata,
> > i2c_set_adapinfo, etc.) are manually called outside probe functions?
> > Or inside the probe function, but not for the device that is being
> > probed (such as is the case with the i801 i2c driver)?
> > 
> > The VFIO driver also does something odd, it clears the driver data,
> > but the device holding it is freed using kfree():
> > 
> > static void vfio_device_release(struct kref *kref) {
> > struct vfio_device *device = container_of(kref,
> >   struct vfio_device, kref);
> > struct vfio_group *group = device->group;
> > 
> > list_del(&device->group_next);
> > mutex_unlock(&group->device_lock);
> > 
> > dev_set_drvdata(device->dev, NULL);
> > 
> > kfree(device);
> > 
> > Is a memory leak also present here since dev_set_drvdata() always tries to
> > allocate memory?
> 
> But it doesn't:
> 
> int dev_set_drvdata(struct device *dev, void *data)
> {
> int error;
> 
> if (!dev->p) {
> error = device_private_init(dev);
> if (error)
> return error;
> }
> dev->p->driver_data = data;
> return 0;
> }

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; 
klist_init(&dev->p->klist_children, klist_children_get,
   klist_children_put);
INIT_LIST_HEAD(&dev->p->deferred_probe);
return 0;
}

and if it doesn't, then I must be missing something in this non-obvious
code. I scanned the interwebs and Documentation/, but could not really
find a great example on how this is supposed to work. The dev_set_drvdata
function existed since Linus moved to git.

> Also, the code referenced is kfree'ing a struct vfio_device, not the
> struct device.  VFIO uses the drvdata to provide a back pointer to the
> vfio specific structure, which also includes a pointer to the struct
> device.  We obviously want to clear drvdata when the vfio specific
> structure is being released.

Ah, I see. "device->dev" is not freed, but "device". And the data is
cleared for "device->dev". Thanks for correcting.

Clear examples of how to use dev_{s,g}et_drvdata correctly in i2c is
still wanted. I stepped in it yesterday, i2c seems to have its own
way to register new devices. More specifically, how can the memory
associated with dev_set_drvdata be free'd on error paths if the
device is not registered with device_register (as is done in the
probe function of the i801 i2c driver)?

Regards,
Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How should dev_[gs]et_drvdata be used? (was: Re: [PATCH] i2c: i801: fix memleak on probe error)

[Peter Wu]

On Monday 23 December 2013 11:51:12 Martin Mokrejs wrote:
> Thanks for the note, was just compiling a new 3.10.24 kernel to test it.
> ;-)
> 
> So far just booted an old 3.9 kernel and after plugging in an external
> USB3 drive I got the message, just to be sure I am still able to reproduce
> the error and that I have the right .config in the running kernel.
> 
> Will wait for another fix instead.
> Martin

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 of setting to NULL on error.
Then device_unregister frees the memory, right?

Now, what if the dev_set_drvdata (or aliases such as pci_set_drvdata,
i2c_set_adapinfo, etc.) are manually called outside probe functions?
Or inside the probe function, but not for the device that is being
probed (such as is the case with the i801 i2c driver)?

The VFIO driver also does something odd, it clears the driver data,
but the device holding it is freed using kfree():

static void vfio_device_release(struct kref *kref) {
struct vfio_device *device = container_of(kref,
  struct vfio_device, kref);
struct vfio_group *group = device->group;

list_del(&device->group_next);
mutex_unlock(&group->device_lock);

dev_set_drvdata(device->dev, NULL);

kfree(device);

Is a memory 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 kmemleak too early, right after boot it did not
> > give any warnings, now it does).
> >
> > RFC: what about dropping i2c_set_adapdata() from the probe function
> > 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 for the device on
> >> success, that led to a memory leak on error paths (for instance, when
> >> there is a resource conflict with ACPI). (The driver core clears the
> >> driver data (if set) if the probe routine fails).
> >>
> >> Fix it by setting the driver data right after successful memory
> >> allocation, before reaching any error paths.
> >>
> >> References: http://lkml.org/lkml/2013/1/23/191
> >> Reported-by: Martin Mokrejs 
> >> Tested-by: Peter Wu  [ACPI conflict error path]
> >> Signed-off-by: Peter Wu 
> >> ---
> >> Hi Jean,
> >>
> >> This memleak issue is still present in v3.13-rc4-256-gb7000ad.
> >>  From kmemleak:
> >>
> >> unreferenced object 0x88022f501a00 (size 256):
> >>comm "systemd-udevd", pid 209, jiffies 4294896115 (age 2872.520s)
> >>hex dump (first 32 bytes):
> >>  00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .N..
> >>  ff ff ff ff ff ff ff ff f4 e2 53 82 ff ff ff ff  ..S.
> >>backtrace:
> >>  [] kmemleak_alloc+0x4e/0xb0
> >>  [] kmem_cache_alloc_trace+0xfa/0x1e0
> >>  [] device_private_init+0x23/0x80
> >>  [] dev_set_drvdata+0x39/0x50
> >>  [] i801_probe+0x59/0x528 [i2c_i801]
> >>  [] local_pci_probe+0x45/0xa0
> >>  [] pci_device_probe+0xd9/0x130
> >>  [] driver_probe_device+0x87/0x390
> >>  [] __driver_attach+0x93/0xa0
> >>  [] bus_for_each_dev+0x6b/0xb0
> >>  [] driver_attach+0x1e/0x20
> >>  [] bus_add_driver+0x188/0x260
> >>  [] driver_register+0x64/0xf0
> >>  [] __pci_register_driver+0x60/0x70
> >>  [] 0xa02990af
> >>  [] do_one_initcall+0xf2/0x1a0
> >>
> >> The dmesg for this laptop also contains a resource conflict message,
> >> just like the reporter (Martin Mokrejs):
> >>
> >>  [   15.409772] ACPI Warning: 0x1840-0x185f 
> >> SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 
> >> (20131115/utaddress-251)
> >>  [   15.413439] ACPI: If an ACPI driver is available for this device, 
> >> you should use it instead of the native driver
> >>
> >> With this patch applied on top of almost 3.13-rc5 (v3.13-rc4-256-gb7000ad),
> >> the memleak is gone.

Re: [PATCH] i2c: i801: fix memleak on probe error

[Peter Wu]

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 about dropping i2c_set_adapdata() from the probe function
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 for the device on
> success, that led to a memory leak on error paths (for instance, when
> there is a resource conflict with ACPI). (The driver core clears the
> driver data (if set) if the probe routine fails).
> 
> Fix it by setting the driver data right after successful memory
> allocation, before reaching any error paths.
> 
> References: http://lkml.org/lkml/2013/1/23/191
> Reported-by: Martin Mokrejs 
> Tested-by: Peter Wu  [ACPI conflict error path]
> Signed-off-by: Peter Wu 
> ---
> Hi Jean,
> 
> This memleak issue is still present in v3.13-rc4-256-gb7000ad.
> From kmemleak:
> 
> unreferenced object 0x88022f501a00 (size 256):
>   comm "systemd-udevd", pid 209, jiffies 4294896115 (age 2872.520s)
>   hex dump (first 32 bytes):
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .N..
> ff ff ff ff ff ff ff ff f4 e2 53 82 ff ff ff ff  ..S.
>   backtrace:
> [] kmemleak_alloc+0x4e/0xb0
> [] kmem_cache_alloc_trace+0xfa/0x1e0
> [] device_private_init+0x23/0x80
> [] dev_set_drvdata+0x39/0x50
> [] i801_probe+0x59/0x528 [i2c_i801]
> [] local_pci_probe+0x45/0xa0
> [] pci_device_probe+0xd9/0x130
> [] driver_probe_device+0x87/0x390
> [] __driver_attach+0x93/0xa0
> [] bus_for_each_dev+0x6b/0xb0
> [] driver_attach+0x1e/0x20
> [] bus_add_driver+0x188/0x260
> [] driver_register+0x64/0xf0
> [] __pci_register_driver+0x60/0x70
> [] 0xa02990af
> [] do_one_initcall+0xf2/0x1a0
> 
> The dmesg for this laptop also contains a resource conflict message,
> just like the reporter (Martin Mokrejs):
> 
> [   15.409772] ACPI Warning: 0x1840-0x185f 
> SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20131115/utaddress-251)
> [   15.413439] ACPI: If an ACPI driver is available for this device, you 
> should use it instead of the native driver
> 
> With this patch applied on top of almost 3.13-rc5 (v3.13-rc4-256-gb7000ad),
> the memleak is gone.
> 
> Regards,
> Peter
> ---
>  drivers/i2c/busses/i2c-i801.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 737e298..a7096bf 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1117,6 +1117,7 @@ static int i801_probe(struct pci_dev *dev, const struct 
> pci_device_id *id)
>   if (!priv)
>   return -ENOMEM;
>  
> + pci_set_drvdata(dev, priv);
>   i2c_set_adapdata(&priv->adapter, priv);
>   priv->adapter.owner = THIS_MODULE;
>   priv->adapter.class = i801_get_adapter_class(priv);
> @@ -1236,8 +1237,6 @@ static int i801_probe(struct pci_dev *dev, const struct 
> pci_device_id *id)
>   /* We ignore errors - multiplexing is optional */
>   i801_add_mux(priv);
>  
> - pci_set_drvdata(dev, priv);
> -
>   return 0;
>  
>  exit_free_irq:
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/