Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 10月, 2012 1 次提交
    • M
      [media] cx18: get rid of warning: no previous prototype · 5e6e81b2
      由 Mauro Carvalho Chehab 提交于 
      drivers/media/pci/cx18/cx18-alsa-main.c:200:5: warning: no previous prototype for 'cx18_alsa_load' [-Wmissing-prototypes]
drivers/media/pci/cx18/cx18-alsa-pcm.c:325:5: warning: no previous prototype for 'snd_cx18_pcm_create' [-Wmissing-prototypes]
drivers/media/pci/cx18/cx18-alsa-pcm.c:72:6: warning: no previous prototype for 'cx18_alsa_announce_pcm_data' [-Wmissing-prototypes]
drivers/media/pci/cx18/cx18-streams.c:100:6: warning: no previous prototype for 'cx18_dma_free' [-Wmissing-prototypes]

Cc: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5e6e81b2
  3. 27 10月, 2012 1 次提交
    • D
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      由 David Härdeman 提交于 
      The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  5. 26 10月, 2012 2 次提交
  7. 19 10月, 2012 1 次提交
  9. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      由 Konstantin Khlebnikov 提交于 
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:

 | effect                 | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump      | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP

This patch removes reserved_vm counter from mm_struct.  Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.

Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.

remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.

[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Venkatesh Pallipadi <venki@google.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  11. 07 10月, 2012 2 次提交
  13. 06 10月, 2012 3 次提交
  15. 02 10月, 2012 9 次提交
  17. 27 9月, 2012 1 次提交
  19. 26 9月, 2012 10 次提交
  21. 24 9月, 2012 3 次提交
  23. 19 9月, 2012 3 次提交
  25. 12 9月, 2012 1 次提交
  27. 10 9月, 2012 1 次提交
  29. 21 8月, 2012 1 次提交
    • M
      [media] saa7164: Add dependency for V4L2 core · b4c723e6
      由 Mauro Carvalho Chehab 提交于 
      As Reported by Randy:

> drivers/built-in.o: In function `fops_open':
> saa7164-encoder.c:(.text+0x68ed6f): undefined reference to `video_devdata'
> drivers/built-in.o: In function `fill_queryctrl.clone.4':
> saa7164-encoder.c:(.text+0x68f657): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-encoder.c:(.text+0x68f6a9): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-encoder.c:(.text+0x68f6e0): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-encoder.c:(.text+0x68f71a): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-encoder.c:(.text+0x68f73a): undefined reference to `v4l2_ctrl_query_fill'
> drivers/built-in.o:saa7164-encoder.c:(.text+0x68f757): more undefined references to `v4l2_ctrl_query_fill' follow
> drivers/built-in.o: In function `saa7164_encoder_register':
> (.text+0x68fff7): undefined reference to `video_device_alloc'
> drivers/built-in.o: In function `saa7164_encoder_register':
> (.text+0x690073): undefined reference to `video_device_release'
> drivers/built-in.o: In function `saa7164_encoder_register':
> (.text+0x6900a1): undefined reference to `__video_register_device'
> drivers/built-in.o: In function `saa7164_encoder_unregister':
> (.text+0x690243): undefined reference to `video_unregister_device'
> drivers/built-in.o: In function `saa7164_encoder_unregister':
> (.text+0x690269): undefined reference to `video_device_release'
> drivers/built-in.o: In function `fops_open':
> saa7164-vbi.c:(.text+0x69125f): undefined reference to `video_devdata'
> drivers/built-in.o: In function `fill_queryctrl.clone.4':
> saa7164-vbi.c:(.text+0x6919b4): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-vbi.c:(.text+0x6919ee): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-vbi.c:(.text+0x691a23): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-vbi.c:(.text+0x691a47): undefined reference to `v4l2_ctrl_query_fill'
> saa7164-vbi.c:(.text+0x691a6a): undefined reference to `v4l2_ctrl_query_fill'
> drivers/built-in.o:saa7164-vbi.c:(.text+0x691a87): more undefined references to `v4l2_ctrl_query_fill' follow
> drivers/built-in.o: In function `saa7164_vbi_register':
> (.text+0x69220e): undefined reference to `video_device_alloc'
> drivers/built-in.o: In function `saa7164_vbi_register':
> (.text+0x69228a): undefined reference to `video_device_release'
> drivers/built-in.o: In function `saa7164_vbi_register':
> (.text+0x6922bb): undefined reference to `__video_register_device'
> drivers/built-in.o: In function `saa7164_vbi_unregister':
> (.text+0x6923de): undefined reference to `video_unregister_device'
> drivers/built-in.o: In function `saa7164_vbi_unregister':
> (.text+0x6923f9): undefined reference to `video_device_release'
> drivers/built-in.o:(.rodata+0xb1054): undefined reference to `video_ioctl2'
> drivers/built-in.o:(.rodata+0xb17d4): undefined reference to `video_ioctl2'

That's due to the lack of an explicit Kconfig dependency for the V4L2 core.
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b4c723e6