[Lucid] SRU: Update to DRM33.11 stable kernel

[chalserogers at gmail.com]

On Wed, Oct 20, 2010 at 1:45 AM, Stefan Bader
<stefan.bader at canonical.com> wrote:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663176
>
> SRU Justification
>
> Impact: The upstream process for stable tree updates is quite similar in scope
> to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and
> each patch is vetted by upstream by originating either directly from Linus' tree
> or in a minimally backported form of that patch.
> Lucid was released with the DRM subsystem updated to the 2.6.33 level because
> 2.6.32 was too unstable there. Until 2.6.33 went out of upstream support, we
> picked the patches for DRM from this tree. After that we now keep an upstream
> tree that continues that effort and selectively picks changes from more recent
> stable kernels or upstream patches that been passing SRU criteria and review.
>
> http://git.kernel.org/?p=linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git;a=shortlog;h=refs/tags/v2.6.32.24.11
>
> TEST CASE: TBD
>
> ==========
>
> The following 12 patches have been in 2.6.32.24.11:
> * i915: return -EFAULT if copy_to_user fails
> * i915_gem: return -EFAULT if copy_to_user fails
> * drm/i915: Prevent double dpms on
> * drm: Only decouple the old_fb from the crtc is we call mode_set*
> * drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
> * drm/i915: Unset cursor if out-of-bounds upon mode change (v4)
> * drm/i915: disable FBC when more than one pipe is active
> * drm/radeon/kms: fix macbookpro connector quirk
> * drm/nouveau: use ALIGN instead of open coding it
> * drm/nouveau: Fix fbcon corruption with font width not divisible by 8
> * drm/i915,agp/intel: Add second set of PCI-IDs for B43
> * Linux 2.6.32.24+drm33.11
>
>
>
> The following patch was reverted and replaced by the upstream version:
> * drm/nouveau: Fix fbcon corruption with font width not divisible by 8 (WARNING!)
>
> Note that the upstream nouveau patch is different from what we had. Probably the
> upstream version is better as it only uses ALIGN where the code had been doing
> alignment calculation. The patch we had added an ALIGN somewhere not aligned
> before. Chris, can you have a quick look to make sure my feeling is not wrong
> here? Thanks.
>
As far as I can tell, the upstream patch leaves the tree in the same
state as the patch we currently have applied - the difference appears
to be in the state *before* the patch is applied, not after.  As such,
it seems plenty safe to me - am I reading the commits properly?
(3c6c5a34 in the new tree, d8655589 in the old).