Skip to content

L
linux
Switch branch/tag
  1. 30 Sep, 2015 13 commits
  3. 29 Sep, 2015 21 commits
  5. 28 Sep, 2015 6 commits
    • Grant Likely's avatar
      drivercore: Fix unregistration path of platform devices · 9965eafe
      Grant Likely authored 
      commit 7f5dcaf1 upstream.

The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.

Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.

* It can be argued that of_platform_populate() should be registering
  it's resources, and they argument has some merit. However, there are
  quite a few platforms that end up broken if we try to do that due to
  overlapping resources in the device tree. Until that is fixed, we need
  to solve the immediate problem.

Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
Tested-by: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Tested-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9965eafe
    • David Daney's avatar
      of/address: Don't loop forever in of_find_matching_node_by_address(). · ea95c941
      David Daney authored 
      commit 3a496b00 upstream.

If the internal call to of_address_to_resource() fails, we end up
looping forever in of_find_matching_node_by_address().  This can be
caused by a defective device tree, or calling with an incorrect
matches argument.

Fix by calling of_find_matching_node() unconditionally at the end of
the loop.
Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
Signed-off-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ea95c941
    • Adrien Schildknecht's avatar
      rtlwifi: rtl8192cu: Add new device ID · 334cf11f
      Adrien Schildknecht authored 
      commit 1642d09f upstream.

The v2 of NetGear WNA1000M uses a different idProduct: USB ID 0846:9043
Signed-off-by: default avatarAdrien Schildknecht <adrien+dev@schischi.me>
Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      334cf11f
    • Jan H. Schönherr's avatar
      sched: Fix cpu_active_mask/cpu_online_mask race · 9ecde004
      Jan H. Schönherr authored 
      commit dd9d3843 upstream.

There is a race condition in SMP bootup code, which may result
in

    WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
    workqueue_cpu_up_callback()
or
    kernel BUG at kernel/smpboot.c:135!

It can be triggered with a bit of luck in Linux guests running
on busy hosts.

	CPU0                        CPUn
	====                        ====

	_cpu_up()
	  __cpu_up()
				    start_secondary()
				      set_cpu_online()
					cpumask_set_cpu(cpu,
						   to_cpumask(cpu_online_bits));
	  cpu_notify(CPU_ONLINE)
	    <do stuff, see below>
					cpumask_set_cpu(cpu,
						   to_cpumask(cpu_active_bits));

During the various CPU_ONLINE callbacks CPUn is online but not
active. Several things can go wrong at that point, depending on
the scheduling of tasks on CPU0.

Variant 1:

  cpu_notify(CPU_ONLINE)
    workqueue_cpu_up_callback()
      rebind_workers()
        set_cpus_allowed_ptr()

  This call fails because it requires an active CPU; rebind_workers()
  ends with a warning:

    WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
    workqueue_cpu_up_callback()

Variant 2:

  cpu_notify(CPU_ONLINE)
    smpboot_thread_call()
      smpboot_unpark_threads()
       ..
        __kthread_unpark()
          __kthread_bind()
          wake_up_state()
           ..
            select_task_rq()
              select_fallback_rq()

  The ->wake_cpu of the unparked thread is not allowed, making a call
  to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
  find an allowed, active CPU and promptly resets the allowed CPUs, so
  that the task in question ends up on CPU0.

  When those unparked tasks are eventually executed, they run
  immediately into a BUG:

    kernel BUG at kernel/smpboot.c:135!

Just changing the order in which the online/active bits are set
(and adding some memory barriers), would solve the two issues
above. However, it would change the order of operations back to
the one before commit 6acbfb96 ("sched: Fix hotplug vs.
set_cpus_allowed_ptr()"), thus, reintroducing that particular
problem.

Going further back into history, we have at least the following
commits touching this topic:
- commit 2baab4e9 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online")
- commit 5fbd036b ("sched: Cleanup cpu_active madness")

Together, these give us the following non-working solutions:

  - secondary CPU sets active before online, because active is assumed to
    be a subset of online;

  - secondary CPU sets online before active, because the primary CPU
    assumes that an online CPU is also active;

  - secondary CPU sets online and waits for primary CPU to set active,
    because it might deadlock.

Commit 875ebe94 ("powerpc/smp: Wait until secondaries are
active & online") introduces an arch-specific solution to this
arch-independent problem.

Now, go for a more general solution without explicit waiting and
simply set active twice: once on the secondary CPU after online
was set and once on the primary CPU after online was seen.

set_cpus_allowed_ptr()")
Signed-off-by: default avatarJan H. Schönherr <jschoenh@amazon.de>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Blanchard <anton@samba.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Wilson <msw@amazon.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9ecde004
    • Jan Kara's avatar
      xfs: Fix file type directory corruption for btree directories · f3897ff3
      Jan Kara authored 
      commit 03754234 upstream.

Users have occasionally reported that file type for some directory
entries is wrong. This mostly happened after updating libraries some
libraries. After some debugging the problem was traced down to
xfs_dir2_node_replace(). The function uses args->filetype as a file type
to store in the replaced directory entry however it also calls
xfs_da3_node_lookup_int() which will store file type of the current
directory entry in args->filetype. Thus we fail to change file type of a
directory entry to a proper type.

Fix the problem by storing new file type in a local variable before
calling xfs_da3_node_lookup_int().
Reported-by: default avatarGiacomo Comes <comes@naic.edu>
Signed-off-by: default avatarJan Kara <jack@suse.com>
Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
[ luis: backported to 3.16:
  - file rename: fs/xfs/libxfs/xfs_dir2_node.c -> fs/xfs/xfs_dir2_node.c ]
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f3897ff3
    • Stephen Chandler Paul's avatar
      DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd · 15b134ca
      Stephen Chandler Paul authored 
      commit 924f92bf upstream.

Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:

	- GPU has only one monitor connected. It's connected via
	  DisplayPort, and does not go through an adaptor of any sort.

	- User unplugs DisplayPort connector from GPU.

	- Change in HPD is detected by the driver, we probe every
	  DisplayPort for a possible connection.

	- Probe the port the user originally had the monitor connected
	  on for it's dpcd. This fails, and we clear the first (and only
	  the first) byte of the dpcd to indicate we no longer have a
	  dpcd for this port.

	- User plugs the previously disconnected monitor back into the
	  same DisplayPort.

	- radeon_connector_hotplug() is called before everyone else,
	  and tries to handle the link training. Since only the first
	  byte of the dpcd is zeroed, the driver is able to complete
	  link training but does so against the wrong dpcd, causing it
	  to initialize the link with the wrong settings.

	- Display stays blank (usually), dpcd is probed after the
	  initial link training, and the driver prints no obvious
	  messages to the log.

In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: default avatarStephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      15b134ca
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7