summaryrefslogtreecommitdiff
path: root/drivers/tty/ehv_bytechan.c
diff options
context:
space:
mode:
authorDavid Herrmann <dh.herrmann@gmail.com>2014-05-25 14:59:47 +0400
committerDavid Herrmann <dh.herrmann@gmail.com>2014-07-08 02:29:53 +0400
commit0cdbe8ac696b5399327f972a1c91263c1a44f1d9 (patch)
tree7ba5705585c5de981a11e41935cd66ad88ce285c /drivers/tty/ehv_bytechan.c
parentab5a60c3ee41ff22304e2bcf63c151aa2851df0c (diff)
downloadlinux-0cdbe8ac696b5399327f972a1c91263c1a44f1d9.tar.xz
drm/gem: remove misleading gfp parameter to get_pages()
drm_gem_get_pages() currently allows passing a 'gfp' parameter that is passed to shmem combined with mapping_gfp_mask(). Given that the default mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will ever make use of that parameter. In fact, all drivers currently pass redundant flags or 0. This patch removes the 'gfp' parameter. The only reason to keep it is to remove flags like __GFP_WAIT. But in its current form, it can only be used to add flags. So to remove __GFP_WAIT, you'd have to drop it from the mapping_gfp_mask, which again is stupid as this mask is used by shmem-core for other allocations, too. If any driver ever requires that parameter, we can introduce a new helper that takes the raw 'gfp' parameter. The caller'd be responsible to combine it with mapping_gfp_mask() in a suitable way. The current drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and call the new helper. This is what shmem_read_mapping_pages{_gfp,} does right now. Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified zone, shmem core will WARN() or even BUG(). In other words, the following must be true for 'gfp' passed to shmem_read_mapping_pages_gfp(): gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp) Add a comment to drm_gem_read_pages() explaining that constraint. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Diffstat (limited to 'drivers/tty/ehv_bytechan.c')
0 files changed, 0 insertions, 0 deletions