linux-toradex.git/drivers, branch v3.7.3

drm/i915: Treat crtc->mode.clock == 0 as disabled

2013-01-17T16:46:50+00:00

commit 3490ea5de6ac4af309c3df8a26a5cca61306334c upstream.

Prevent a divide-by-zero by consistently treating an 'active' CRTC
without a mode set as actually disabled.

This looks to have been first introduced with

commit 24929352481f085c5f85d4d4cbc919ddf106d381
Author: Daniel Vetter 
Date:   Mon Jul 2 20:28:59 2012 +0200

    drm/i915: read out the modeset hw state at load and resume time

but then combined with

commit b0a2658acb5bf9ca86b4aab011b7106de3af0add
Author: Daniel Vetter 
Date:   Tue Dec 18 09:37:54 2012 +0100

    drm/i915: don't disable disconnected outputs

it finally started oopsing.

Signed-off-by: Chris Wilson 
Reported-and-tested-by: Alexey Zaytsev 
Tested-by: Sedat Dilek 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

i915: ensure that VGA plane is disabled

2013-01-17T16:46:50+00:00

commit 0fde901f1ddd2ce0e380a6444f1fb7ca555859e9 upstream.

Some broken systems (like HP nc6120) in some cases, usually after LID
close/open, enable VGA plane, making display unusable (black screen on LVDS,
some strange mode on VGA output). We used to disable VGA plane only once at
startup. Now we also check, if VGA plane is still disabled while changing
mode, and fix that if something changed it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
Signed-off-by: Krzysztof Mazur 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: force restore on lid open

2013-01-17T16:46:50+00:00

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 upstream.

There seem to be indeed some awkwards machines around, mostly those
without OpRegion support, where the firmware changes the display hw
state behind our backs when closing the lid.

This force-restore logic has been originally introduced in

commit c1c7af60892070e4b82ad63bbfb95ae745056de0
Author: Jesse Barnes 
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time

but after the modeset-rework we've disabled it in the vain hope that
it's no longer required:

commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d
Author: Daniel Vetter 
Date:   Mon Sep 17 22:27:21 2012 +0200

    drm/i915: fix OOPS in lid_notify

Alas, no.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
Tested-by: Krzysztof Mazur 
Reviewed-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

rbd: get rid of RBD_MAX_SEG_NAME_LEN

2013-01-17T16:46:49+00:00

(cherry picked from commit 2fd82b9e92c2a718ae81fc987b4468ceeee6979b)

RBD_MAX_SEG_NAME_LEN represents the maximum length of an rbd object
name (i.e., one of the objects providing storage backing an rbd
image).

Another symbol, MAX_OBJ_NAME_SIZE, is used in the osd client code to
define the maximum length of any object name in an osd request.

Right now they disagree, with RBD_MAX_SEG_NAME_LEN being too big.

There's no real benefit at this point to defining the rbd object
name length limit separate from any other object name, so just
get rid of RBD_MAX_SEG_NAME_LEN and use MAX_OBJ_NAME_SIZE in its
place.

Signed-off-by: Alex Elder 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

rbd: do not allow remove of mounted-on image

2013-01-17T16:46:49+00:00

(cherry picked from commit 42382b709bd1d143b9f0fa93e0a3a1f2f4210707)

There is no check in rbd_remove() to see if anybody holds open the
image being removed.  That's not cool.

Add a simple open count that goes up and down with opens and closes
(releases) of the device, and don't allow an rbd image to be removed
if the count is non-zero.

Protect the updates of the open count value with ctl_mutex to ensure
the underlying rbd device doesn't get removed while concurrently
being opened.

Signed-off-by: Alex Elder 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

rbd: remove snapshots on error in rbd_add()

2013-01-17T16:46:49+00:00

(cherry picked from commit 41f38c2b2f8b66b176a0e548ef06294343a7bfa2)

If rbd_dev_snaps_update() has ever been called for an rbd device
structure there could be snapshot structures on its snaps list.
In rbd_add(), this function is called but a subsequent error
path neglected to clean up any of these snapshots.

Add a call to rbd_remove_all_snaps() in the appropriate spot to
remedy this.  Change a couple of error labels to be a little
clearer while there.

Drop the leading underscores from the function name; there's nothing
special about that function that they might signify.  As suggested
in review, the leading underscores in __rbd_remove_snap_dev() have
been removed as well.

Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin 
Signed-off-by: Greg Kroah-Hartman

rbd: increase maximum snapshot name length

2013-01-17T16:46:49+00:00

(cherry picked from commit d4b125e9eb43babd14538ba61718e3db71a98d29)

Change RBD_MAX_SNAP_NAME_LEN to be based on NAME_MAX.  That is a
practical limit for the length of a snapshot name (based on the
presence of a directory using the name under /sys/bus/rbd to
represent the snapshot).

The /sys entry is created by prefixing it with "snap_"; define that
prefix symbolically, and take its length into account in defining
the snapshot name length limit.

Enforce the limit in rbd_add_parse_args().  Also delete a dout()
call in that function that was not meant to be committed.

Signed-off-by: Alex Elder 
Reviewed-by: Dan Mick 
Reviewed-by: Josh Durgin 
Signed-off-by: Greg Kroah-Hartman

rbd: fix read-only option name

2013-01-17T16:46:49+00:00

(cherry picked from commit be466c1cc36621590ef17b05a6d342dfd33f7280)

The name of the "read-only" mapping option was inadvertently changed
in this commit:

    f84344f3 rbd: separate mapping info in rbd_dev

Revert that hunk to return it to what it should be.

Signed-off-by: Alex Elder 
Reviewed-by: Dan Mick 
Reviewed-by: Josh Durgin 
Signed-off-by: Greg Kroah-Hartman

rbd: zero return code in rbd_dev_image_id()

2013-01-17T16:46:49+00:00

(cherry picked from commit a0ea3a40fd20b8c66381f747c454f89d6d1f50d4)

When rbd_dev_probe() calls rbd_dev_image_id() it expects to get
a 0 return code if successful, but it is getting a positive value.

The reason is that rbd_dev_image_id() returns the value it gets from
rbd_req_sync_exec(), which returns the number of bytes read in as a
result of the request.  (This ultimately comes from
ceph_copy_from_page_vector() in rbd_req_sync_op()).

Force the return value to 0 when successful in rbd_dev_image_id().
Do the same in rbd_dev_v2_object_prefix().

Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin 
Reviewed-by: Dan Mick 
Signed-off-by: Greg Kroah-Hartman

rbd: fix bug in rbd_dev_id_put()

2013-01-17T16:46:48+00:00

(cherry picked from commit b213e0b1a62637b2a9395a34349b13d73ca2b90a)

In rbd_dev_id_put(), there's a loop that's intended to determine
the maximum device id in use.  But it isn't doing that at all,
the effect of how it's written is to simply use the just-put id
number, which ignores whole purpose of this function.

Fix the bug.

Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin 
Signed-off-by: Greg Kroah-Hartman