config SND_OMAP_SOC tristate "SoC Audio for the Texas Instruments OMAP chips" depends on (ARCH_OMAP && DMA_OMAP) || (ARM && COMPILE_TEST) select SND_DMAENGINE_PCM config SND_OMAP_SOC_DMIC tristate config SND_OMAP_SOC_MCBSP tristate config SND_OMAP_SOC_MCPDM tristate config SND_OMAP_SOC_HDMI_AUDIO tristate "HDMI audio support for OMAP4+ based SoCs" depends on SND_OMAP_SOC help For HDMI audio to work OMAPDSS HDMI support should be enabled. The hdmi audio driver implements cpu-dai component using the callbacks provided by OMAPDSS and registers the component under DSS HDMI device. Omap-pcm is registered for platform component also under DSS HDMI device. Dummy codec is used as as codec component. The hdmi audio driver implements also the card and registers it under its own platform device. The device for the driver is registered by OMAPDSS hdmi driver. config SND_OMAP_SOC_N810 tristate "SoC Audio support for Nokia N810" depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C depends on OMAP_MUX select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC3X help Say Y if you want to add support for SoC audio on Nokia N810. config SND_OMAP_SOC_RX51 tristate "SoC Audio support for Nokia N900 (RX-51)" depends on SND_OMAP_SOC && ARM && I2C select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC3X select SND_SOC_TPA6130A2 depends on GPIOLIB help Say Y if you want to add support for SoC audio on Nokia N900 cellphone. config SND_OMAP_SOC_AMS_DELTA tristate "SoC Audio support for Amstrad E3 (Delta) videophone" depends on SND_OMAP_SOC && MACH_AMS_DELTA && TTY select SND_OMAP_SOC_MCBSP select SND_SOC_CX20442 help Say Y if you want to add support for SoC audio device connected to a handset and a speakerphone found on Amstrad E3 (Delta) videophone. Note that in order to get those devices fully supported, you have to build the kernel with standard serial port driver included and configured for at least 4 ports. Then, from userspace, you must load a line discipline #19 on the modem (ttyS3) serial line. The simplest way to achieve this is to install util-linux-ng and use the included ldattach utility. This can be started automatically from udev, a simple rule like this one should do the trick (it does for me): ACTION=="add", KERNEL=="controlC0", \ RUN+="/usr/sbin/ldattach 19 /dev/ttyS3" config SND_OMAP_SOC_OSK5912 tristate "SoC Audio support for omap osk5912" depends on SND_OMAP_SOC && MACH_OMAP_OSK && I2C select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC23_I2C help Say Y if you want to add support for SoC audio on osk5912. config SND_OMAP_SOC_AM3517EVM tristate "SoC Audio support for OMAP3517 / AM3517 EVM" depends on SND_OMAP_SOC && MACH_OMAP3517EVM && I2C select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC23_I2C help Say Y if you want to add support for SoC audio on the OMAP3517 / AM3517 EVM. config SND_OMAP_SOC_OMAP_TWL4030 tristate "SoC Audio support for TI SoC based boards with twl4030 codec" depends on TWL4030_CORE && SND_OMAP_SOC select SND_OMAP_SOC_MCBSP select SND_SOC_TWL4030 help Say Y if you want to add support for SoC audio on TI SoC based boards using twl4030 as c codec. This driver currently supports: - Beagleboard or Devkit8000 - Gumstix Overo or CompuLab CM-T35/CM-T3730 - IGEP v2 - OMAP3EVM - SDP3430 - Zoom2 config SND_OMAP_SOC_OMAP_ABE_TWL6040 tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" depends on TWL6040_CORE && SND_OMAP_SOC && COMMON_CLK depends on ARCH_OMAP4 || (SOC_OMAP5 && MFD_PALMAS) || COMPILE_TEST select SND_OMAP_SOC_DMIC select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 select SND_SOC_DMIC select COMMON_CLK_PALMAS if (SOC_OMAP5 && MFD_PALMAS) select CLK_TWL6040 help Say Y if you want to add support for SoC audio on OMAP boards using ABE and twl6040 codec. This driver currently supports: - SDP4430/Blaze boards - PandaBoard (4430) - PandaBoardES (4460) - omap5-uevm (5432) config SND_OMAP_SOC_OMAP3_PANDORA tristate "SoC Audio support for OMAP3 Pandora" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_PANDORA select SND_OMAP_SOC_MCBSP select SND_SOC_TWL4030 help Say Y if you want to add support for SoC audio on the OMAP3 Pandora. mit-info'> authorGianluca Borello <g.borello@gmail.com>2017-01-09 10:19:49 -0800 committerDavid S. Miller <davem@davemloft.net>2017-01-09 16:56:27 -0500 commit06c1c049721a995dee2829ad13b24aaf5d7c5cce (patch) tree732383611199bb0556ee56d3454d50609714c48e /include/xen parentf0318d01b694485af9678a4e120328ae3555be6d (diff)
bpf: allow helpers access to variable memory
Currently, helpers that read and write from/to the stack can do so using a pair of arguments of type ARG_PTR_TO_STACK and ARG_CONST_STACK_SIZE. ARG_CONST_STACK_SIZE accepts a constant register of type CONST_IMM, so that the verifier can safely check the memory access. However, requiring the argument to be a constant can be limiting in some circumstances. Since the current logic keeps track of the minimum and maximum value of a register throughout the simulated execution, ARG_CONST_STACK_SIZE can be changed to also accept an UNKNOWN_VALUE register in case its boundaries have been set and the range doesn't cause invalid memory accesses. One common situation when this is useful: int len; char buf[BUFSIZE]; /* BUFSIZE is 128 */ if (some_condition) len = 42; else len = 84; some_helper(..., buf, len & (BUFSIZE - 1)); The compiler can often decide to assign the constant values 42 or 48 into a variable on the stack, instead of keeping it in a register. When the variable is then read back from stack into the register in order to be passed to the helper, the verifier will not be able to recognize the register as constant (the verifier is not currently tracking all constant writes into memory), and the program won't be valid. However, by allowing the helper to accept an UNKNOWN_VALUE register, this program will work because the bitwise AND operation will set the range of possible values for the UNKNOWN_VALUE register to [0, BUFSIZE), so the verifier can guarantee the helper call will be safe (assuming the argument is of type ARG_CONST_STACK_SIZE_OR_ZERO, otherwise one more check against 0 would be needed). Custom ranges can be set not only with ALU operations, but also by explicitly comparing the UNKNOWN_VALUE register with constants. Another very common example happens when intercepting system call arguments and accessing user-provided data of variable size using bpf_probe_read(). One can load at runtime the user-provided length in an UNKNOWN_VALUE register, and then read that exact amount of data up to a compile-time determined limit in order to fit into the proper local storage allocated on the stack, without having to guess a suboptimal access size at compile time. Also, in case the helpers accepting the UNKNOWN_VALUE register operate in raw mode, disable the raw mode so that the program is required to initialize all memory, since there is no guarantee the helper will fill it completely, leaving possibilities for data leak (just relevant when the memory used by the helper is the stack, not when using a pointer to map element value or packet). In other words, ARG_PTR_TO_RAW_STACK will be treated as ARG_PTR_TO_STACK. Signed-off-by: Gianluca Borello <g.borello@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/xen')