BMC/Intel-BMC/linux.git/drivers/media/pci, branch dev-4.6

Merge branch 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2016-03-21T02:08:56+00:00

Pull x86 protection key support from Ingo Molnar: "This tree adds support for a new memory protection hardware feature that is available in upcoming Intel CPUs: 'protection keys' (pkeys). There's a background article at LWN.net: https://lwn.net/Articles/643797/ The gist is that protection keys allow the encoding of user-controllable permission masks in the pte. So instead of having a fixed protection mask in the pte (which needs a system call to change and works on a per page basis), the user can map a (handful of) protection mask variants and can change the masks runtime relatively cheaply, without having to change every single page in the affected virtual memory range. This allows the dynamic switching of the protection bits of large amounts of virtual memory, via user-space instructions. It also allows more precise control of MMU permission bits: for example the executable bit is separate from the read bit (see more about that below). This tree adds the MM infrastructure and low level x86 glue needed for that, plus it adds a high level API to make use of protection keys - if a user-space application calls: mmap(..., PROT_EXEC); or mprotect(ptr, sz, PROT_EXEC); (note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice this special case, and will set a special protection key on this memory range. It also sets the appropriate bits in the Protection Keys User Rights (PKRU) register so that the memory becomes unreadable and unwritable. So using protection keys the kernel is able to implement 'true' PROT_EXEC on x86 CPUs: without protection keys PROT_EXEC implies PROT_READ as well. Unreadable executable mappings have security advantages: they cannot be read via information leaks to figure out ASLR details, nor can they be scanned for ROP gadgets - and they cannot be used by exploits for data purposes either. We know about no user-space code that relies on pure PROT_EXEC mappings today, but binary loaders could start making use of this new feature to map binaries and libraries in a more secure fashion. There is other pending pkeys work that offers more high level system call APIs to manage protection keys - but those are not part of this pull request. Right now there's a Kconfig that controls this feature (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled (like most x86 CPU feature enablement code that has no runtime overhead), but it's not user-configurable at the moment. If there's any serious problem with this then we can make it configurable and/or flip the default" * 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (38 commits) x86/mm/pkeys: Fix mismerge of protection keys CPUID bits mm/pkeys: Fix siginfo ABI breakage caused by new u64 field x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA mm/core, x86/mm/pkeys: Add execute-only protection keys support x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags x86/mm/pkeys: Allow kernel to modify user pkey rights register x86/fpu: Allow setting of XSAVE state x86/mm: Factor out LDT init from context init mm/core, x86/mm/pkeys: Add arch_validate_pkey() mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits() x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU x86/mm/pkeys: Add Kconfig prompt to existing config option x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps x86/mm/pkeys: Dump PKRU with other kernel registers mm/core, x86/mm/pkeys: Differentiate instruction fetches x86/mm/pkeys: Optimize fault handling in access_error() mm/core: Do not enforce PKEY permissions on remote mm access um, pkeys: Add UML arch_*_access_permitted() methods mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys x86/mm/gup: Simplify get_user_pages() PTE bit handling ...

[media] saa7134: fix warning with !MEDIA_CONTROLLER

2016-03-03T17:12:46+00:00

When CONFIG_MEDIA_CONTROLLER is disabled, we get a warning about an unused function: drivers/media/pci/saa7134/saa7134-core.c:832:13: error: 'saa7134_create_entities' defined but not used [-Werror=unused-function] This moves the #ifdef outside of the function, as it is never called here. Fixes: ac90aa02d5b9 ("[media] saa7134: add media controller support") Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab

[media] cx23885: incorrect I2C bus used in the CI registration

2016-03-03T15:08:07+00:00

This patch fixes a bug that was introduced by the commit: commit 2b0aac3011bc7a9db27791bed4978554263ef079 Author: Mauro Carvalho Chehab [media] cx23885: move CI/MAC registration to a separate function Signed-off-by: Olli Salonen Signed-off-by: Mauro Carvalho Chehab

[media] cx23885: fix reversed I2C bus numbering

2016-03-03T13:05:11+00:00

I2C buses for DVBSky T980C and S950C were numbered in an opposite way compared to every other board in the driver. Switch numbering to a more logical way. Signed-off-by: Olli Salonen Signed-off-by: Mauro Carvalho Chehab

[media] saa7134: Add support for Snazio TvPVR PRO

2016-03-03T12:03:48+00:00

This board has PCI ID: 1779:13cf [mchehab@osg.samsung.com: Make scripts/checkpatch.pl happy] Signed-off-by: Pojar George Signed-off-by: Mauro Carvalho Chehab

[media] pt3: fix device identification

2016-03-01T15:01:45+00:00

As warned by smatch: drivers/media/pci/pt3/pt3.c:398 pt3_attach_fe() error: strncmp() '"tc90522sat"' too small (11 vs 20) Clearly, the logic is doing the wrong thing, as it is not comparing the strings on the right way. Signed-off-by: Mauro Carvalho Chehab

[media] bttv: Width must be a multiple of 16 when capturing planar formats

2016-03-01T13:36:24+00:00

On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max size results in a solid green rectangle being captured (all colors 0 in YUV). This turns out to be caused by max-width (924) not being a multiple of 16. We've likely never hit this problem before since normally xawtv / tvtime, etc. will prefer packed pixel formats. But when using a video card which is using xf86-video-modesetting + glamor, only planar XVideo fmts are available, and xawtv will chose a matching capture format to avoid needing to do conversion, triggering the solid green window problem. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] ttpci: cleanup a bogus smatch warning

2016-02-23T10:26:22+00:00

Cleanup this bogus smatch warning: drivers/media/pci/ttpci/budget.c:635 frontend_init() warn: missing break? reassigning 'budget->dvb_frontend' And document the fall through logic at the switch(). Signed-off-by: Mauro Carvalho Chehab

[media] av7110: remove a bogus smatch warning

2016-02-23T10:25:21+00:00

Remove this bogus smatch warning: drivers/media/pci/ttpci/av7110.c:2211 frontend_init() warn: missing break? reassigning 'av7110->fe' Signed-off-by: Mauro Carvalho Chehab

[media] ivtv: steal could be NULL

2016-02-23T10:22:22+00:00

ivtv_flush_queues() calls ivtv_queue_move() with steal == NULL. However, part of the code assumes that steal could be not null, as pointed by smatch: drivers/media/pci/ivtv/ivtv-queue.c:145 ivtv_queue_move() error: we previously assumed 'steal' could be null (see line 138) This has the potential of causing an OOPS when the queue is flushed. Signed-off-by: Mauro Carvalho Chehab