Skip to content

L
linux
Switch branch/tag
  1. 21 Oct, 2015 34 commits
  3. 20 Oct, 2015 6 commits
    • Grant Likely's avatar
      drivercore: Fix unregistration path of platform devices · d9e87bf3
      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 avatarKamal Mostafa <kamal@canonical.com>
      d9e87bf3
    • David Daney's avatar
      of/address: Don't loop forever in of_find_matching_node_by_address(). · f8275f3c
      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 avatarKamal Mostafa <kamal@canonical.com>
      f8275f3c
    • Adrien Schildknecht's avatar
      rtlwifi: rtl8192cu: Add new device ID · f5a1711c
      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 avatarKamal Mostafa <kamal@canonical.com>
      f5a1711c
    • Marek Vasut's avatar
      rtlwifi: rtl8192cu: Add new device ID · 18dac284
      Marek Vasut authored 
      commit 9374e7d2 upstream.

Add new ID for ASUS N10 WiFi dongle.
Signed-off-by: default avatarMarek Vasut <marex@denx.de>
Tested-by: default avatarMarek Vasut <marex@denx.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      18dac284
    • Stephen Chandler Paul's avatar
      DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd · a18b0993
      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 avatarKamal Mostafa <kamal@canonical.com>
      a18b0993
    • Filipe Manana's avatar
      Btrfs: check if previous transaction aborted to avoid fs corruption · 7f527cfe
      Filipe Manana authored 
      commit 1f9b8c8f upstream.

While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
aborted after we waited for it to commit, so we ended up committing the
current transaction which can lead to fs corruption because the new
superblock can point to trees that have had one or more nodes/leafs that
were never durably persisted.
The following sequence diagram exemplifies how this is possible:

          CPU 0                                                        CPU 1

  transaction N starts

  (...)

  btrfs_commit_transaction(N)

    cur_trans->state = TRANS_STATE_COMMIT_START;
    (...)
    cur_trans->state = TRANS_STATE_COMMIT_DOING;
    (...)

    cur_trans->state = TRANS_STATE_UNBLOCKED;
    root->fs_info->running_transaction = NULL;

                                                              btrfs_start_transaction()
                                                                 --> starts transaction N + 1

    btrfs_write_and_wait_transaction(trans, root);
      --> starts writing all new or COWed ebs created
          at transaction N

                                                              creates some new ebs, COWs some
                                                              existing ebs but doesn't COW or
                                                              deletes eb X

                                                              btrfs_commit_transaction(N + 1)
                                                                (...)
                                                                cur_trans->state = TRANS_STATE_COMMIT_START;
                                                                (...)
                                                                wait_for_commit(root, prev_trans);
                                                                  --> prev_trans == transaction N

    btrfs_write_and_wait_transaction() continues
    writing ebs
       --> fails writing eb X, we abort transaction N
           and set bit BTRFS_FS_STATE_ERROR on
           fs_info->fs_state, so no new transactions
           can start after setting that bit

       cleanup_transaction()
         btrfs_cleanup_one_transaction()
           wakes up task at CPU 1

                                                                continues, doesn't abort because
                                                                cur_trans->aborted (transaction N + 1)
                                                                is zero, and no checks for bit
                                                                BTRFS_FS_STATE_ERROR in fs_info->fs_state
                                                                are made

                                                                btrfs_write_and_wait_transaction(trans, root);
                                                                  --> succeeds, no errors during writeback

                                                                write_ctree_super(trans, root, 0);
                                                                  --> succeeds
                                                                  --> we have now a superblock that points us
                                                                      to some root that uses eb X, which was
                                                                      never written to disk

In this scenario future attempts to read eb X from disk results in an
error message like "parent transid verify failed on X wanted Y found Z".

So fix this by aborting the current transaction if after waiting for the
previous transaction we verify that it was aborted.
Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
Signed-off-by: default avatarChris Mason <clm@fb.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7f527cfe
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7