Eric Lee / smarc-fsl-linux-kernel

17 Jun, 2007

1 commit

  • f4d278173   fix radeon setparam on 32/64 systems, harder. ... Browse Code »

    Commit 9b01bd5b284bbf519b726b39f1352023cb5e9e69 introduced a
    compat_ioctl handler for RADEON_SETPARAM, the sole purpose of which was
    to handle the fact that on i386, alignof(uint64_t)==4.

    Unfortunately, this handler was installed for _all_ 64-bit
    architectures, instead of only x86_64 and ia64. And thus it breaks
    32-bit compatibility on every other arch, where 64-bit integers are
    aligned to 8 bytes in 32-bit mode just the same as in 64-bit mode.

    Arnd has a cunning plan to use 'compat_u64' with appropriate alignment
    attributes according to the 32-bit ABI, but for now let's just make the
    compat_radeon_cp_setparam routine entirely disappear on 64-bit machines
    whose 32-bit compat support isn't for i386. It would be a no-op with
    compat_u64 anyway.

    Signed-off-by: David Woodhouse
    Acked-by: Arnd Bergmann
    Cc: Benjamin Herrenschmidt
    Cc: Dave Airlie
    Signed-off-by: Linus Torvalds

    David Woodhouse
     

10 Jun, 2007

1 commit

09 Dec, 2006

1 commit

11 Jan, 2006

1 commit

25 Sep, 2005

1 commit

  • b5e89ed53   drm: lindent the drm directory. ... Browse Code »

    I've been threatening this for a while, so no point hanging around.
    This lindents the DRM code which was always really bad in tabbing department.
    I've also fixed some misnamed files in comments and removed some trailing
    whitespace.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

23 Jun, 2005

1 commit

  • 9a1866450   drm: 32/64-bit DRM ioctl compatibility patch ... Browse Code »

    The patch is against a 2.6.11 kernel tree. I am running this with a
    32-bit X server (compiled up from X.org CVS as of a couple of weeks
    ago) and 32-bit DRI libraries and clients. All the userland stuff is
    identical to what I am using under a 32-bit kernel on my G4 powerbook
    (which is a 32-bit machine of course). I haven't tried compiling up a
    64-bit X server or clients yet.

    In the compatibility routines I have assumed that the kernel can
    safely access user addresses after set_fs(KERNEL_DS). That is, where
    an ioctl argument structure contains pointers to other structures, and
    those other structures are already compatible between the 32-bit and
    64-bit ABIs (i.e. they only contain things like chars, shorts or
    ints), I just check the address with access_ok() and then pass it
    through to the 64-bit ioctl code. I believe this approach may not
    work on sparc64, but it does work on ppc64 and x86_64 at least.

    One tricky area which may need to be revisited is the question of how
    to handle the handles which we pass back to userspace to identify
    mappings. These handles are generated in the ADDMAP ioctl and then
    passed in as the offset value to mmap. However, offset values for
    mmap seem to be generated in other ways as well, particularly for AGP
    mappings.

    The approach I have ended up with is to generate a fake 32-bit handle
    only for _DRM_SHM mappings. The handles for other mappings (AGP, REG,
    FB) are physical addresses which are already limited to 32 bits, and
    generating fake handles for them created all sorts of problems in the
    mmap/nopage code.

    This patch has been updated to use the new compatibility ioctls.

    From: Paul Mackerras
    Signed-off-by: Dave Airlie

    Dave Airlie