BMC/Intel-BMC/linux.git/drivers/char/agp/frontend.c, branch dev

agp: remove read/write stubs

2014-08-01T20:43:51+00:00

The VFS layer handles those in the very same way, if unset. No need for additional stubs. Signed-off-by: Mathias Krause Cc: Alexander Viro Signed-off-by: Dave Airlie

agp: info leak in agpioc_info_wrap()

2014-05-06T20:05:00+00:00

On 64 bit systems the agp_info struct has a 4 byte hole between ->agp_mode and ->aper_base. We need to clear it to avoid disclosing stack information to userspace. Signed-off-by: Dan Carpenter Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drivers/char: delete non-required instances of include

2014-02-07T23:10:19+00:00

None of these files are actually using any __init type directives and hence don't need to include . Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Cc: David Airlie Cc: Matt Mackall Cc: Herbert Xu Cc: Kukjin Kim Cc: Corey Minyard Cc: Chris Metcalf Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Peter Huewe Cc: Ashley Lai Cc: Marcel Selhorst Signed-off-by: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman

drm, agpgart: Use pgprot_writecombine for AGP maps and make the MTRR optional

2013-05-31T03:37:31+00:00

I'm not sure I understand the intent of the previous behavior. mmap on /dev/agpgart and DRM_AGP maps had no cache flags set, so they would be fully cacheable. But the DRM code (most of the time) would add a write-combining MTRR that would change the effective memory type to WC. The new behavior just requests WC explicitly for all AGP maps. If there is any code out there that expects cacheable access to the AGP aperture (because the drm driver doesn't request an MTRR or because it's using /dev/agpgart directly), then it will now end up with a UC or WC mapping, depending on the architecture and PAT availability. But cacheable access to the aperture seems like it's asking for trouble, because, AIUI, the aperture is an alias of RAM. Reviewed-by: Daniel Vetter Signed-off-by: Andy Lutomirski Signed-off-by: Dave Airlie

agp: kill agp_flush_chipset and corresponding ioctl

2010-11-23T20:14:45+00:00

The intel drm calls the chipset functions now directly. Userspace never called the corresponding ioctl, hence it can be killed, too. Cc: Dave Airlie Signed-off-by: Daniel Vetter Signed-off-by: Chris Wilson

BKL: remove extraneous #include

2010-11-17T16:59:32+00:00

The big kernel lock has been removed from all these files at some point, leaving only the #include. Remove this too as a cleanup. Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds

agp: Remove the BKL from agp_open

2009-10-14T15:36:54+00:00

- Remove the BKL from agp_open - Perform a few clean-ups. Analysis: --------- int minor is local to the function. The following are protected by agp_fe.agp_mutex struct agp_file_private *priv; struct agp_client *client; Call-outs: kzalloc should be safe to call under the mutex_lock agp_find_client_by_pid: - agp_mmap calls that under agp_fe.agp_mutex which we hold in agp_open - agpioc_reserve_wrap calls it without any locking what-so-ever. - Is that an error? Or is that okay because it has pid that is a unique handle? agp_insert_file_private: - This function only manipulates struct agp_file_private, once again while agp_fe.agp_mutex is held Signed-off-by: John Kacur Acked-by: David Airlie LKML-Reference: Signed-off-by: Thomas Gleixner

Merge commit 'v2.6.26' into bkl-removal

2008-07-14T21:29:34+00:00

agp-frontend: BKL pushdown

2008-06-20T20:05:54+00:00

Signed-off-by: Arnd Bergmann

agp: more boolean conversions.

2008-06-19T00:42:17+00:00

Signed-off-by: Dave Airlie