Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 6月, 2005 1 次提交
    • D
      drm: 32/64-bit DRM ioctl compatibility patch · 9a186645
      由 Dave Airlie 提交于 
      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 <paulus@samba.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      9a186645
  3. 22 6月, 2005 3 次提交
  5. 21 6月, 2005 6 次提交
  7. 19 6月, 2005 1 次提交
  9. 10 6月, 2005 2 次提交
  11. 08 6月, 2005 4 次提交
    • D
      [PATCH] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). · 66bb8bf8
      由 David Mosberger 提交于 
      [AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0).

As mentioned earlier, the current check_bridge_mode() code assumes
that AGP bridges are PCI devices.  This isn't always true.  Definitely
not for HP zx1 chipset and the same seems to be the case for SGI's AGP
bridge.

The patch below fixes the problem by picking up the AGP_MODE_3_0 bit
from bridge->mode.  I feel like I may be missing something, since I
can't see any reason why check_bridge_mode() wasn't doing that in the
first place.  According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is
determined during the hardware reset and cannot be changed, so it
seems to me it should be safe to pick it up from bridge->mode.

With the patch applied, I can definitely use AGP acceleration both
with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an
ATI FireGL card).

Unless someone spots a problem, please apply this patch so 3d
acceleration can work on zx1 boxes again.

This makes AGP work again on machines with an AGP bridge that isn't a
PCI device.
Signed-off-by: NDavid Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: NDave Jones <davej@redhat.com>
      66bb8bf8
    • K
      [PATCH] AGP fix for Xen VMM · 07eee78e
      由 Keir Fraser 提交于 
      When Linux is running on the Xen virtual machine monitor, physical
addresses are virtualised and cannot be directly referenced by the AGP
GART.  This patch fixes the GART driver for Xen by adding a layer of
abstraction between physical addresses and 'GART addresses'.

Architecture-specific functions are also defined for allocating and freeing
the GATT.  Xen requires this to ensure that table really is contiguous from
the point of view of the GART.

These extra interface functions are defined as 'no-ops' for all existing
architectures that use the GART driver.
Signed-off-by: NKeir Fraser <keir@xensource.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDave Jones <davej@redhat.com>
      07eee78e
    • M
      [PATCH] sgi-agp: fixes a problem with accessing GART memory in... · e29b545c
      由 Michael Werner 提交于 
      [PATCH] sgi-agp: fixes a problem with accessing GART memory in sgi_tioca_insert_memory and sgi_tioca_remove_memory

This patch fixes a problem with accessing GART memory in
sgi_tioca_insert_memory and sgi_tioca_remove_memory.

 sgi-agp.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)
Signed-off-by: NMike Werner <werner@sgi.com>
Signed-off-by: NDave Jones <davej@redhat.com>
      e29b545c
    • A
      [PATCH] i945G patch for agpgart · d0de98fa
      由 Alan Hourihane 提交于 
      Attached is a small patch for i945G support against 2.6.11.11.

From: Alan Hourihane <alanh@fairlite.demon.co.uk>
Signed-off-by: NDave Jones <davej@redhat.com>
      d0de98fa
  13. 07 6月, 2005 1 次提交
  15. 26 5月, 2005 1 次提交
  17. 20 5月, 2005 1 次提交
  19. 19 5月, 2005 1 次提交
    • S
      [PATCH] Fix filp being passed through raw ioctl handler · e72022e1
      由 Stephen Tweedie 提交于 
      Don't pass meaningless file handles to block device ioctls.

The recent raw IO ioctl-passthrough fix started passing the raw file
handle into the block device ioctl handler.  That's unlikely to be
useful, as the file handle is actually open on a character-mode raw
device, not a block device, so dereferencing it is not going to yield
useful results to a block device ioctl handler.

Previously we just passed NULL; also not a value that can usefully
be dereferenced, but at least if it does happen, we'll oops instead of
silently pretending that the file is a block device, so NULL is the more
defensive option here.  This patch reverts to that behaviour.

Noticed by Al Viro.
Signed-off-by: NStephen Tweedie <sct@redhat.com>
Acked-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e72022e1
  21. 17 5月, 2005 2 次提交
    • P
      [PATCH] Intel 6300ESB TCO timer support · a123edab
      由 Peter Lundkvist 提交于 
      Additional i8xx_tco device support.

Cc: David Hardeman <david@2gen.com>
Cc: <wim@iguana.be>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a123edab
    • S
      [PATCH] Fix root hole in raw device · 68f66feb
      由 Stephen Tweedie 提交于 
      [Patch] Fix raw device ioctl pass-through

Raw character devices are supposed to pass ioctls through to the block
devices they are bound to.  Unfortunately, they are using the wrong
function for this: ioctl_by_bdev(), instead of blkdev_ioctl().

ioctl_by_bdev() performs a set_fs(KERNEL_DS) before calling the ioctl,
redirecting the user-space buffer access to the kernel address space.
This is, needless to say, a bad thing.

This was noticed first on s390, where raw IO was non-functioning.  The
s390 driver config does not actually allow raw IO to be enabled, which
was the first part of the problem.  Secondly, the s390 kernel address
space is distinct from user, causing legal raw ioctls to fail.  I've
reproduced this on a kernel built with 4G:4G split on x86, which fails
in the same way (-EFAULT if the address does not exist kernel-side;
returns success without actually populating the user buffer if it does.)

The patch below fixes both the config and address-space problems.  It's
based closely on a patch by Jan Glauber <jang@de.ibm.com>, which has
been tested on s390 at IBM.  I've tested it on x86 4G:4G (split address
space) and x86_64 (common address space).

Kernel-address-space access has been assigned CAN-2005-1264.
Signed-off-by: NStephen Tweedie <sct@redhat.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      68f66feb
  23. 06 5月, 2005 2 次提交
  25. 04 5月, 2005 5 次提交
  27. 01 5月, 2005 10 次提交