aboutsummaryrefslogtreecommitdiff
path: root/include/uapi/linux
Commit message (Collapse)AuthorAgeFilesLines
* Revert "ASoC: Add support for AFE custom topology"Chaosmaster2020-12-071-23/+1
| | | | | | This reverts commit 0fe8ea54460f45142c6acb21b33173477da7c0da. Change-Id: Id34d97f4edaf8904db06b7a854b0c9ffb7329d5c
* shm: add sealing APIDavid Herrmann2019-11-171-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If two processes share a common memory region, they usually want some guarantees to allow safe access. This often includes: - one side cannot overwrite data while the other reads it - one side cannot shrink the buffer while the other accesses it - one side cannot grow the buffer beyond previously set boundaries If there is a trust-relationship between both parties, there is no need for policy enforcement. However, if there's no trust relationship (eg., for general-purpose IPC) sharing memory-regions is highly fragile and often not possible without local copies. Look at the following two use-cases: 1) A graphics client wants to share its rendering-buffer with a graphics-server. The memory-region is allocated by the client for read/write access and a second FD is passed to the server. While scanning out from the memory region, the server has no guarantee that the client doesn't shrink the buffer at any time, requiring rather cumbersome SIGBUS handling. 2) A process wants to perform an RPC on another process. To avoid huge bandwidth consumption, zero-copy is preferred. After a message is assembled in-memory and a FD is passed to the remote side, both sides want to be sure that neither modifies this shared copy, anymore. The source may have put sensible data into the message without a separate copy and the target may want to parse the message inline, to avoid a local copy. While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide ways to achieve most of this, the first one is unproportionally ugly to use in libraries and the latter two are broken/racy or even disabled due to denial of service attacks. This patch introduces the concept of SEALING. If you seal a file, a specific set of operations is blocked on that file forever. Unlike locks, seals can only be set, never removed. Hence, once you verified a specific set of seals is set, you're guaranteed that no-one can perform the blocked operations on this file, anymore. An initial set of SEALS is introduced by this patch: - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced in size. This affects ftruncate() and open(O_TRUNC). - GROW: If SEAL_GROW is set, the file in question cannot be increased in size. This affects ftruncate(), fallocate() and write(). - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) are possible. This affects fallocate(PUNCH_HOLE), mmap() and write(). - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. This basically prevents the F_ADD_SEAL operation on a file and can be set to prevent others from adding further seals that you don't want. The described use-cases can easily use these seals to provide safe use without any trust-relationship: 1) The graphics server can verify that a passed file-descriptor has SEAL_SHRINK set. This allows safe scanout, while the client is allowed to increase buffer size for window-resizing on-the-fly. Concurrent writes are explicitly allowed. 2) For general-purpose IPC, both processes can verify that SEAL_SHRINK, SEAL_GROW and SEAL_WRITE are set. This guarantees that neither process can modify the data while the other side parses it. Furthermore, it guarantees that even with writable FDs passed to the peer, it cannot increase the size to hit memory-limits of the source process (in case the file-storage is accounted to the source). The new API is an extension to fcntl(), adding two new commands: F_GET_SEALS: Return a bitset describing the seals on the file. This can be called on any FD if the underlying file supports sealing. F_ADD_SEALS: Change the seals of a given file. This requires WRITE access to the file and F_SEAL_SEAL may not already be set. Furthermore, the underlying file must support sealing and there may not be any existing shared mapping of that file. Otherwise, EBADF/EPERM is returned. The given seals are _added_ to the existing set of seals on the file. You cannot remove seals again. The fcntl() handler is currently specific to shmem and disabled on all files. A file needs to explicitly support sealing for this interface to work. A separate syscall is added in a follow-up, which creates files that support sealing. There is no intention to support this on other file-systems. Semantics are unclear for non-volatile files and we lack any use-case right now. Therefore, the implementation is specific to shmem. Change-Id: I62d745211c73661ff8725a64dd2fdeed1b08d335 Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Hugh Dickins <hughd@google.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Ryan Lortie <desrt@desrt.ca> Cc: Lennart Poettering <lennart@poettering.net> Cc: Daniel Mack <zonque@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
* shm: add memfd_create() syscallDavid Herrmann2019-11-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor that you can pass to mmap(). It can support sealing and avoids any connection to user-visible mount-points. Thus, it's not subject to quotas on mounted file-systems, but can be used like malloc()'ed memory, but with a file-descriptor to it. memfd_create() returns the raw shmem file, so calls like ftruncate() can be used to modify the underlying inode. Also calls like fstat() will return proper information and mark the file as regular file. If you want sealing, you can specify MFD_ALLOW_SEALING. Otherwise, sealing is not supported (like on all other regular files). Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not subject to a filesystem size limit. It is still properly accounted to memcg limits, though, and to the same overcommit or no-overcommit accounting as all user memory. Change-Id: I4dbb81e751ec310f680fdcb386024de31dfe01fe Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Hugh Dickins <hughd@google.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Ryan Lortie <desrt@desrt.ca> Cc: Lennart Poettering <lennart@poettering.net> Cc: Daniel Mack <zonque@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
* ipv4: expose IPV4_DEVCONFstephen hemminger2019-08-071-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IP sends device configuration (see inet_fill_link_af) as an array in the netlink information, but the indices in that array are not exposed to userspace through any current santized header file. It was available back in 2.6.32 (in /usr/include/linux/sysctl.h) but was broken by: commit 02291680ffba92e5b5865bc0c5e7d1f3056b80ec Author: Eric W. Biederman <ebiederm@xmission.com> Date: Sun Feb 14 03:25:51 2010 +0000 net ipv4: Decouple ipv4 interface parameters from binary sysctl numbers Eric was solving the sysctl problem but then the indices were re-exposed by a later addition of devconf support for IPV4 commit 9f0f7272ac9506f4c8c05cc597b7e376b0b9f3e4 Author: Thomas Graf <tgraf@infradead.org> Date: Tue Nov 16 04:32:48 2010 +0000 ipv4: AF_INET link address family Putting them in /usr/include/linux/ip.h seemed the logical match for the DEVCONF_ definitions for IPV6 in /usr/include/linux/ip6.h Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 4a5a8aa6c966eafc106543bd955ae388230420e5) Change-Id: I705b167bb03f7a70b08e17b6d3c1ad8bea1aae17
* ASoC: Add support for AFE custom topologyLaxminath Kasam2019-07-311-1/+23
| | | | | | | | | Inorder to support AFE custom topology, make changes in AFE driver to send AFE calibration based on custom flag set. Change-Id: I95391e12d93eca7385e249ad9eda323679e92388 Signed-off-by: Laxminath Kasam <lkasam@codeaurora.org>
* tcp: tcp_fragment() should apply sane memory limitsEric Dumazet2019-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream. Jonathan Looney reported that a malicious peer can force a sender to fragment its retransmit queue into tiny skbs, inflating memory usage and/or overflow 32bit counters. TCP allows an application to queue up to sk_sndbuf bytes, so we need to give some allowance for non malicious splitting of retransmit queue. A new SNMP counter is added to monitor how many times TCP did not allow to split an skb if the allowance was exceeded. Note that this counter might increase in the case applications use SO_SNDBUF socket option to lower sk_sndbuf. CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the socket is already using more than half the allowed space Change-Id: I594a9f68263f774fa6f0824042bc287bba6dc927 Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* [BACKPORT]: binder: create node flag to request sender's security contextTodd Kjos2019-06-201-0/+19
| | | | | | | | | | | | | | | | | | | | To allow servers to verify client identity, allow a node flag to be set that causes the sender's security context to be delivered with the transaction. The BR_TRANSACTION command is extended in BR_TRANSACTION_SEC_CTX to contain a pointer to the security context string. Signed-off-by: Todd Kjos <tkjos@google.com> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ec74136ded792deed80780a2f8baf3521eeb72f9 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master) Change-Id: I44496546e2d0dc0022f818a45cd52feb1c1a92cb Signed-off-by: Todd Kjos <tkjos@google.com> [@dev-harsh1998]: Adjust context for 3.10 Signed-off-by: dev-harsh1998 <harshitjain6751@gmail.com>
* [BACKPORT]: ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.Martijn Coenen2019-06-201-0/+10
| | | | | | | | | | | | | | | | | This allows the context manager to retrieve information about nodes that it holds a reference to, such as the current number of references to those nodes. Such information can for example be used to determine whether the servicemanager is the only process holding a reference to a node. This information can then be passed on to the process holding the node, which can in turn decide whether it wants to shut down to reduce resource usage. Signed-off-by: Martijn Coenen <maco@android.com> [@dev-harsh1998]: Adjust for our backport. Signed-off-by: dev-harsh1998 <dev-harsh1998@hotmail.com> Change-Id: Ic599039c0bffa61b618703987577f96b32a454f2
* binder: make FIFO inheritance a per-context optionTim Murray2019-06-201-0/+1
| | | | | | | | | | | | | Add a new ioctl to binder to control whether FIFO inheritance should happen. In particular, hwbinder should inherit FIFO priority from callers, but standard binder threads should not. Test: boots bug 36516194 Signed-off-by: Tim Murray <timmurray@google.com> Change-Id: I8100c4364b7d15d1bf00a8ca5c286e4d4b23ce85
* Add BINDER_GET_NODE_DEBUG_INFO ioctlColin Cross2019-06-201-0/+14
| | | | | | | | | | | | | The BINDER_GET_NODE_DEBUG_INFO ioctl will return debug info on a node. Each successive call reusing the previous return value will return the next node. The data will be used by libmemunreachable to mark the pointers with kernel references as reachable. Bug: 28275695 Change-Id: Idbbafa648a33822dc023862cd92b51a595cf7c1c Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Martijn Coenen <maco@android.com>
* ANDROID: binder: add RT inheritance flag to node.Martijn Coenen2019-06-201-0/+8
| | | | | | | | Allows a binder node to specify whether it wants to inherit real-time scheduling policy from a caller. Change-Id: I375b6094bf441c19f19cba06d5a6be02cd07d714 Signed-off-by: Martijn Coenen <maco@android.com>
* ANDROID: binder: add min sched_policy to node.Martijn Coenen2019-06-201-1/+40
| | | | | | | | | | | | | | | | This change adds flags to flat_binder_object.flags to allow indicating a minimum scheduling policy for the node. It also clarifies the valid value range for the priority bits in the flags. Internally, we use the priority map that the kernel uses, e.g. [0..99] for real-time policies and [100..139] for the SCHED_NORMAL/SCHED_BATCH policies. Bug: 34461621 Bug: 37293077 Change-Id: I12438deecb53df432da18c6fc77460768ae726d2 Signed-off-by: Martijn Coenen <maco@google.com>
* xattr: Constify ->name member of "struct xattr".Tetsuo Handa2019-06-071-1/+1
| | | | | | | | | | | | | | | | | Since everybody sets kstrdup()ed constant string to "struct xattr"->name but nobody modifies "struct xattr"->name , we can omit kstrdup() and its failure checking by constifying ->name member of "struct xattr". Change-Id: I84a47af13e3c77b394218cc12ac8901d87b0fd69 Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Joel Becker <jlbec@evilplan.org> [ocfs2] Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Reviewed-by: Paul Moore <paul@paul-moore.com> Tested-by: Paul Moore <paul@paul-moore.com> Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
* cfg80211: add extensible feature flag attributeGautam Kumar Shukla2019-05-111-0/+20
| | | | | | | | | | | | | | | With the wiphy::features flag being used up this patch adds a new field wiphy::ext_features. Considering extensibility this new field is declared as a byte array. This extensible flag is exposed to user-space by NL80211_ATTR_EXT_FEATURES. Change-Id: I2464e1b464fa2349d805f53c693b38e9ad28409c Cc: Avinash Patil <patila@marvell.com> Signed-off-by: Gautam (Gautam Kumar) Shukla <gautams@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Felipe Leon <fglfgl27@gmail.com> Signed-off-by: Julian Veit <claymore1298@gmail.com>
* BACKPORT: ipv6 addrconf: implement RFC7559 router solicitation backoffMaciej Żenczykowski2019-04-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This implements: https://tools.ietf.org/html/rfc7559 Backoff is performed according to RFC3315 section 14: https://tools.ietf.org/html/rfc3315#section-14 We allow setting /proc/sys/net/ipv6/conf/*/router_solicitations to a negative value meaning an unlimited number of retransmits, and we make this the new default (inline with the RFC). We also add a new setting: /proc/sys/net/ipv6/conf/*/router_solicitation_max_interval defaulting to 1 hour (per RFC recommendation). Signed-off-by: Maciej Żenczykowski <maze@google.com> Acked-by: Erik Kline <ek@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit bd11f0741fa5a2c296629898ad07759dd12b35bb in DaveM's net-next/master, should make Linus' tree in 4.9-rc1) Change-Id: Ia32cdc5c61481893ef8040734e014bf2229fc39e Git-commit: ce2d59ac01f3b8d29441d29449653fb25bb83f2a Git-repo: https://android.googlesource.com/kernel/common.git [resolved trivial merge conflicts] Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* net: ipv6: Add sysctl for minimum prefix len acceptable in RIOs.Joel Scherpelz2019-04-122-0/+14
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a new sysctl accept_ra_rt_info_min_plen that defines the minimum acceptable prefix length of Route Information Options. The new sysctl is intended to be used together with accept_ra_rt_info_max_plen to configure a range of acceptable prefix lengths. It is useful to prevent misconfigurations from unintentionally blackholing too much of the IPv6 address space (e.g., home routers announcing RIOs for fc00::/7, which is incorrect). [backport of net-next bbea124bc99df968011e76eba105fe964a4eceab] Bug: 33333670 Test: net_test passes Change-Id: I5be36ef0e71b4fa9083d7aad2cbb00dd281d778f Signed-off-by: Joel Scherpelz <jscherpelz@google.com> Acked-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Git-commit: 161e88ebebc748d1fa51055fc31be6c98db3316e Git-repo: https://android.googlesource.com/kernel/common.git Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* Initial AudioWizard bringupLaster K2019-02-031-0/+21
| | | | | | | Ported from Asus ZS551KL kernel source. Change-Id: I1d040d01788b18521d75ecccacf7d38b65cf065a Signed-off-by: Laster K. (lazerl0rd) <officiallazerl0rd@gmail.com>
* Revert "Initial AudioWizard bringup"Julian Veit2019-02-031-23/+0
| | | | This reverts commit 8c504d32bc187af37babaede09e6564cfa0ee726.
* ASoC: add G711 audio encoding supportPreetam Singh Ranawat2019-02-022-0/+18
| | | | | | | | | | G711 PCM is a commonly used waveform speech codec. add native audio drivers for both G711 mlaw and G711 alaw encoding formats. CRs-Fixed: 990836 Change-Id: Ia187948fab9840447b1f5b1ede4e9a1ece0b85c5 Signed-off-by: Preetam Singh Ranawat <apranawat@codeaurora.org>
* uapi: Export sockaddr_storage for userspaceEthan Chen2018-09-181-0/+7
| | | | Change-Id: I3851f40de8481ae32d43df3d96fe1fb9988233ce
* net: rmnet_data: Add support to configure custom device nameSubash Abhinov Kasiviswanathan2018-09-181-2/+13
| | | | | | | | | | | | | | rmnet_data assigns device name by the order they are created. This causes problems which multiple processes are trying to create devices and leads to random device names. Assign device name as specified by user. [mikeioannina]: Backport to 3.10 CRs-Fixed: 2018785 Change-Id: Iab8e053c6ccacbeedaa7763e760d0c12e756b5d0 Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
* import latest N HTC kernel source code [1/2]Julian Veit2018-08-196-76/+179
| | | | | | | | | | | * HTC package version: 4.19.617.6_R taken out: exfat: we use newer samsung impl sdcard: newer impl is currently present camera: this will done in a follow up commit ([2/2]) Change-Id: I54f0acbf3dea0d41b79f4aab61434580a11be7cc
* Initial AudioWizard bringupLaster K2018-07-201-0/+23
| | | | | | Ported from Asus ZS551KL kernel source. Signed-off-by: Laster K. <officiallazerl0rd@gmail.com>
* Revert "wcd port modern dts hpx and dts sa+"Julian Veit2018-07-181-15/+0
| | | | This reverts commit a46890c67165b56f6a5437028902364fe4b7eebb.
* Revert "DTS: fix out of bounds issue for DTS mod"Julian Veit2018-07-181-1/+2
| | | | This reverts commit 58286da8bdb7f53dc24c773034e4dd1b88440b95.
* Merge tag 'v3.10.107' into lineage-15.1Julian Veit2018-07-082-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the 3.10.107 stable release Conflicts: arch/x86/mm/mmap.c drivers/char/Kconfig drivers/input/joystick/xpad.c drivers/mmc/host/sdhci.c drivers/usb/gadget/composite.c drivers/usb/host/xhci-plat.c fs/ext4/super.c kernel/sched/core.c mm/memory.c mm/mempolicy.c
| * uapi: fix linux/packet_diag.h userspace compilation errorDmitry V. Levin2017-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 745cb7f8a5de0805cade3de3991b7a95317c7c73 upstream. Replace MAX_ADDR_LEN with its numeric value to fix the following linux/packet_diag.h userspace compilation error: /usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here (not in a function) __u8 pdmc_addr[MAX_ADDR_LEN]; This is not the first case in the UAPI where the numeric value of MAX_ADDR_LEN is used instead of symbolic one, uapi/linux/if_link.h already does the same: $ grep MAX_ADDR_LEN include/uapi/linux/if_link.h __u8 mac[32]; /* MAX_ADDR_LEN */ There are no UAPI headers besides these two that use MAX_ADDR_LEN. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Acked-by: Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
| * can: raw: raw_setsockopt: limit number of can_filter that can be setMarc Kleine-Budde2017-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream. This patch adds a check to limit the number of can_filters that can be set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER are not prevented resulting in a warning. Reference: https://lkml.org/lkml/2016/12/2/230 Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Willy Tarreau <w@1wt.eu>
* | Merge tag 'v3.10.102' into lineage-15.1Julian Veit2018-07-051-0/+3
|\| | | | | | | | | | | | | | | | | | | This is the 3.10.102 stable release Conflicts: drivers/mmc/card/block.c drivers/mmc/core/core.c drivers/mmc/core/mmc.c kernel/trace/trace_printk.c
| * linux/const.h: Add _BITUL() and _BITULL()H. Peter Anvin2016-06-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2fc016c5bd8aad2e201cdf71b9fb4573f94775bd upstream. Add macros for single bit definitions of a specific type. These are similar to the BIT() macro that already exists, but with a few exceptions: 1. The namespace is such that they can be used in uapi definitions. 2. The type is set with the _AC() macro to allow it to be used in assembly. 3. The type is explicitly specified to be UL or ULL. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/n/tip-nbca8p7cg6jyjoit7klh3o91@git.kernel.org [wt: backported to 3.10 only to keep next patch clean] Signed-off-by: Willy Tarreau <w@1wt.eu>
* | Merge tag 'v3.10.85' into lineage-15.1Julian Veit2018-07-031-1/+2
|\| | | | | | | | | | | | | | | This is the 3.10.85 stable release Conflicts: drivers/mmc/card/block.c drivers/usb/dwc3/gadget.c
| * USB: usbfs: allow URBs to be reaped after disconnectionAlan Stern2015-08-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3f2cee73b650921b2e214bf487b2061a1c266504 upstream. The usbfs API has a peculiar hole: Users are not allowed to reap their URBs after the device has been disconnected. There doesn't seem to be any good reason for this; it is an ad-hoc inconsistency. The patch allows users to issue the USBDEVFS_REAPURB and USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts on 64-bit systems) even after the device is gone. If no URBs are pending for a disconnected device then the ioctls will return -ENODEV rather than -EAGAIN, because obviously no new URBs will ever be able to complete. The patch also adds a new capability flag for USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect feature is supported. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Chris Dickens <christopher.a.dickens@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | DTS: fix out of bounds issue for DTS modfreak072018-06-011-2/+1
| | | | | | | | (cherry picked from commit https://github.com/freak07/Kirisakura_Taimen_8.1.0/commit/b58124b0ae78803a774f0d5a413821034a7e3eac)
* | wcd port modern dts hpx and dts sa+Laster K2018-06-011-0/+15
| | | | | | | | | | | | Port of DTS Audio (both SA+ and Eagle) for newer versions of Android [than CAF supported]. SA+ is used as a fallback if Eagle cannot be started (check logs usually missing a *.so file somewhere). If you would like to use, please credit me in both authorship and relavent thread (if you declare my DTS port as a feature on your thread). This is for all you HTC 10 users.
* | i2c/rt5506: Export header for userspaceEthan Chen2018-01-172-0/+127
| | | | | | | | Change-Id: I153961c4312583a6682c89935639b36da1df18e1
* | i2c/tfa9895: Export header for userspaceEthan Chen2018-01-172-0/+51
| | | | | | | | Change-Id: Id05c42efd2054024bac62256a61d8a7ba7a5d1aa
* | sdcardfs: Change magic valueDaniel Rosenberg2017-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | Sdcardfs uses the same magic value as wrapfs. This should not be the case. As it is entirely in memory, the value can be changed without any loss of compatibility. Change-Id: I24200b805d5e6d32702638be99e47d50d7f2f746 Signed-off-by: Daniel Rosenberg <drosen@google.com>
* | BACKPORT: random: introduce getrandom(2) system callTheodore Ts'o2017-11-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost clean cherry pick of c6e9d6f38894798696f23c8084ca7edbf16ee895, includes change made by merge 0891ad829d2a0501053703df66029e843e3b8365. The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely. The other feature provided by this new system call is the ability to request randomness from the /dev/urandom entropy pool, but to block until at least 128 bits of entropy has been accumulated in the /dev/urandom entropy pool. Historically, the emphasis in the /dev/urandom development has been to ensure that urandom pool is initialized as quickly as possible after system boot, and preferably before the init scripts start execution. This is because changing /dev/urandom reads to block represents an interface change that could potentially break userspace which is not acceptable. In practice, on most x86 desktop and server systems, in general the entropy pool can be initialized before it is needed (and in modern kernels, we will printk a warning message if not). However, on an embedded system, this may not be the case. And so with this new interface, we can provide the functionality of blocking until the urandom pool has been initialized. Any userspace program which uses this new functionality must take care to assure that if it is used during the boot process, that it will not cause the init scripts or other portions of the system startup to hang indefinitely. SYNOPSIS #include <linux/random.h> int getrandom(void *buf, size_t buflen, unsigned int flags); DESCRIPTION The system call getrandom() fills the buffer pointed to by buf with up to buflen random bytes which can be used to seed user space random number generators (i.e., DRBG's) or for other cryptographic uses. It should not be used for Monte Carlo simulations or other programs/algorithms which are doing probabilistic sampling. If the GRND_RANDOM flags bit is set, then draw from the /dev/random pool instead of the /dev/urandom pool. The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number of bytes may not be returned. If there is no entropy available at all, getrandom(2) will either block, or return an error with errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags. If the GRND_RANDOM bit is not set, then the /dev/urandom pool will be used. Unlike using read(2) to fetch data from /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will block (or return -1 with the errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags). The getentropy(2) system call in OpenBSD can be emulated using the following function: int getentropy(void *buf, size_t buflen) { int ret; if (buflen > 256) goto failure; ret = getrandom(buf, buflen, 0); if (ret < 0) return ret; if (ret == buflen) return 0; failure: errno = EIO; return -1; } RETURN VALUE On success, the number of bytes that was filled in the buf is returned. This may not be all the bytes requested by the caller via buflen if insufficient entropy was present in the /dev/random pool, or if the system call was interrupted by a signal. On error, -1 is returned, and errno is set appropriately. ERRORS EINVAL An invalid flag was passed to getrandom(2) EFAULT buf is outside the accessible address space. EAGAIN The requested entropy was not available, and getentropy(2) would have blocked if the GRND_NONBLOCK flag was not set. EINTR While blocked waiting for entropy, the call was interrupted by a signal handler; see the description of how interrupted read(2) calls on "slow" devices are handled with and without the SA_RESTART flag in the signal(7) man page. NOTES For small requests (buflen <= 256) getrandom(2) will not return EINTR when reading from the urandom pool once the entropy pool has been initialized, and it will return all of the bytes that have been requested. This is the recommended way to use getrandom(2), and is designed for compatibility with OpenBSD's getentropy() system call. However, if you are using GRND_RANDOM, then getrandom(2) may block until the entropy accounting determines that sufficient environmental noise has been gathered such that getrandom(2) will be operating as a NRBG instead of a DRBG for those people who are working in the NIST SP 800-90 regime. Since it may block for a long time, these guarantees do *not* apply. The user may want to interrupt a hanging process using a signal, so blocking until all of the requested bytes are returned would be unfriendly. For this reason, the user of getrandom(2) MUST always check the return value, in case it returns some error, or if fewer bytes than requested was returned. In the case of !GRND_RANDOM and small request, the latter should never happen, but the careful userspace code (and all crypto code should be careful) should check for this anyway! Finally, unless you are doing long-term key generation (and perhaps not even then), you probably shouldn't be using GRND_RANDOM. The cryptographic algorithms used for /dev/urandom are quite conservative, and so should be sufficient for all purposes. The disadvantage of GRND_RANDOM is that it can block, and the increased complexity required to deal with partially fulfilled getrandom(2) requests. Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Zach Brown <zab@zabbo.net> Bug: http://b/29621447 Change-Id: I189ba74070dd6d918b0fdf83ff30bb74ec0f7556 (cherry picked from commit 4af712e8df998475736f3e2727701bd31e3751a9)
* | net: core: add UID to flows, rules, and routesLorenzo Colitti2017-11-142-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Define a new FIB rule attributes, FRA_UID_RANGE, to describe a range of UIDs. - Define a RTA_UID attribute for per-UID route lookups and dumps. - Support passing these attributes to and from userspace via rtnetlink. The value INVALID_UID indicates no UID was specified. - Add a UID field to the flow structures. [Backport of net-next 622ec2c9d52405973c9f1ca5116eb1c393adfc7d] Bug: 16355602 Change-Id: I7e3ab388ed862c4b7e39dc8b0209d977cb1129ac Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Revert "net: core: Support UID-based routing."Lorenzo Colitti2017-11-142-3/+0
| | | | | | | | | | | | | | This reverts commit f6f535d3e0d8da2b5bc3c93690c47485d29e4ce6. Bug: 16355602 Change-Id: I5987e276f5ddbe425ea3bd86861cee0ae22212d9
* | UPSTREAM: capabilities: ambient capabilitiesAndy Lutomirski2017-11-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Credit where credit is due: this idea comes from Christoph Lameter with a lot of valuable input from Serge Hallyn. This patch is heavily based on Christoph's patch. ===== The status quo ===== On Linux, there are a number of capabilities defined by the kernel. To perform various privileged tasks, processes can wield capabilities that they hold. Each task has four capability masks: effective (pE), permitted (pP), inheritable (pI), and a bounding set (X). When the kernel checks for a capability, it checks pE. The other capability masks serve to modify what capabilities can be in pE. Any task can remove capabilities from pE, pP, or pI at any time. If a task has a capability in pP, it can add that capability to pE and/or pI. If a task has CAP_SETPCAP, then it can add any capability to pI, and it can remove capabilities from X. Tasks are not the only things that can have capabilities; files can also have capabilities. A file can have no capabilty information at all [1]. If a file has capability information, then it has a permitted mask (fP) and an inheritable mask (fI) as well as a single effective bit (fE) [2]. File capabilities modify the capabilities of tasks that execve(2) them. A task that successfully calls execve has its capabilities modified for the file ultimately being excecuted (i.e. the binary itself if that binary is ELF or for the interpreter if the binary is a script.) [3] In the capability evolution rules, for each mask Z, pZ represents the old value and pZ' represents the new value. The rules are: pP' = (X & fP) | (pI & fI) pI' = pI pE' = (fE ? pP' : 0) X is unchanged For setuid binaries, fP, fI, and fE are modified by a moderately complicated set of rules that emulate POSIX behavior. Similarly, if euid == 0 or ruid == 0, then fP, fI, and fE are modified differently (primary, fP and fI usually end up being the full set). For nonroot users executing binaries with neither setuid nor file caps, fI and fP are empty and fE is false. As an extra complication, if you execute a process as nonroot and fE is set, then the "secure exec" rules are in effect: AT_SECURE gets set, LD_PRELOAD doesn't work, etc. This is rather messy. We've learned that making any changes is dangerous, though: if a new kernel version allows an unprivileged program to change its security state in a way that persists cross execution of a setuid program or a program with file caps, this persistent state is surprisingly likely to allow setuid or file-capped programs to be exploited for privilege escalation. ===== The problem ===== Capability inheritance is basically useless. If you aren't root and you execute an ordinary binary, fI is zero, so your capabilities have no effect whatsoever on pP'. This means that you can't usefully execute a helper process or a shell command with elevated capabilities if you aren't root. On current kernels, you can sort of work around this by setting fI to the full set for most or all non-setuid executable files. This causes pP' = pI for nonroot, and inheritance works. No one does this because it's a PITA and it isn't even supported on most filesystems. If you try this, you'll discover that every nonroot program ends up with secure exec rules, breaking many things. This is a problem that has bitten many people who have tried to use capabilities for anything useful. ===== The proposed change ===== This patch adds a fifth capability mask called the ambient mask (pA). pA does what most people expect pI to do. pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and then calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can re-add bits to pA afterwards. The capability evolution rules are changed: pA' = (file caps or setuid or setgid ? 0 : pA) pP' = (X & fP) | (pI & fI) | pA' pI' = pI pE' = (fE ? pP' : pA') X is unchanged If you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA = CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah! Unprivileged users can create user namespaces, map themselves to a nonzero uid, and create both privileged (relative to their namespace) and unprivileged process trees. This is currently more or less impossible. Hallelujah! You cannot use pA to try to subvert a setuid, setgid, or file-capped program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch. Users with nonzero pA are unlikely to unintentionally leak that capability. If they run programs that try to drop privileges, dropping privileges will still work. It's worth noting that the degree of paranoia in this patch could possibly be reduced without causing serious problems. Specifically, if we allowed pA to persist across executing non-pA-aware setuid binaries and across setresuid, then, naively, the only capabilities that could leak as a result would be the capabilities in pA, and any attacker *already* has those capabilities. This would make me nervous, though -- setuid binaries that tried to privilege-separate might fail to do so, and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have unexpected side effects. (Whether these unexpected side effects would be exploitable is an open question.) I've therefore taken the more paranoid route. We can revisit this later. An alternative would be to require PR_SET_NO_NEW_PRIVS before setting ambient capabilities. I think that this would be annoying and would make granting otherwise unprivileged users minor ambient capabilities (CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than it is with this patch. ===== Footnotes ===== [1] Files that are missing the "security.capability" xattr or that have unrecognized values for that xattr end up with has_cap set to false. The code that does that appears to be complicated for no good reason. [2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities. [3] Linux very confusingly processes both the script and the interpreter if applicable, for reasons that elude me. The results from thinking about a script's file capabilities and/or setuid bits are mostly discarded. Preliminary userspace code is here, but it needs updating: https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&id=7f5afbd175d2 Here is a test program that can be used to verify the functionality (from Christoph): /* * Test program for the ambient capabilities. This program spawns a shell * that allows running processes with a defined set of capabilities. * * (C) 2015 Christoph Lameter <cl@linux.com> * Released under: GPL v3 or later. * * * Compile using: * * gcc -o ambient_test ambient_test.o -lcap-ng * * This program must have the following capabilities to run properly: * Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE * * A command to equip the binary with the right caps is: * * setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test * * * To get a shell with additional caps that can be inherited by other processes: * * ./ambient_test /bin/bash * * * Verifying that it works: * * From the bash spawed by ambient_test run * * cat /proc/$$/status * * and have a look at the capabilities. */ /* * Definitions from the kernel header files. These are going to be removed * when the /usr/include files have these defined. */ static void set_ambient_cap(int cap) { int rc; capng_get_caps_process(); rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap); if (rc) { printf("Cannot add inheritable cap\n"); exit(2); } capng_apply(CAPNG_SELECT_CAPS); /* Note the two 0s at the end. Kernel checks for these */ if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) { perror("Cannot set cap"); exit(1); } } int main(int argc, char **argv) { int rc; set_ambient_cap(CAP_NET_RAW); set_ambient_cap(CAP_NET_ADMIN); set_ambient_cap(CAP_SYS_NICE); printf("Ambient_test forking shell\n"); if (execv(argv[1], argv + 1)) perror("Cannot exec"); return 0; } Signed-off-by: Christoph Lameter <cl@linux.com> # Original author Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Aaron Jones <aaronmdjones@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Andrew G. Morgan <morgan@kernel.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Austin S Hemmelgarn <ahferroin7@gmail.com> Cc: Markku Savela <msa@moth.iki.fi> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: James Morris <james.l.morris@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 58319057b7847667f0c9585b9de0e8932b0fdb08) Bug: 31038224 Test: Builds. Change-Id: I55fbe6e6d3fbb48edbea15bedd81d90ed50fd575 Signed-off-by: Jorge Lucangeli Obes <jorgelo@google.com>
* | android: binder: add padding to binder_fd_array_object.Martijn Coenen2017-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | binder_fd_array_object starts with a 4-byte header, followed by a few fields that are 8 bytes when ANDROID_BINDER_IPC_32BIT=N. This can cause alignment issues in a 64-bit kernel with a 32-bit userspace, as on x86_32 an 8-byte primitive may be aligned to a 4-byte address. Pad with a __u32 to fix this. Signed-off-by: Martijn Coenen <maco@android.com> Git-commit: a388cf91c7fd5279e923e167af59925826b055d5 Git-repo: https://android.googlesource.com/kernel/common Change-Id: I4374ed2cc3ccd3c6a1474cb7209b53ebfd91077b Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org> [code change is done in relocated file] Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* | android: binder: support for file-descriptor arrays.Martijn Coenen2017-11-141-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new binder_fd_array object, that allows us to support one or more file descriptors embedded in a buffer that is scatter-gathered. Change-Id: I647a53cf0d905c7be0dfd9333806982def68dd74 Signed-off-by: Martijn Coenen <maco@google.com> Git-commit: 274d9fe58c752246db888696a1bc441b041f8215 Git-repo: https://android.googlesource.com/kernel/common.git Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* | android: binder: support for scatter-gather.Martijn Coenen2017-11-141-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously all data passed over binder needed to be serialized, with the exception of Binder objects and file descriptors. This patchs adds support for scatter-gathering raw memory buffers into a binder transaction, avoiding the need to first serialize them into a Parcel. To remain backwards compatibile with existing binder clients, it introduces two new command ioctls for this purpose - BC_TRANSACTION_SG and BC_REPLY_SG. These commands may only be used with the new binder_transaction_data_sg structure, which adds a field for the total size of the buffers we are scatter-gathering. Because memory buffers may contain pointers to other buffers, we allow callers to specify a parent buffer and an offset into it, to indicate this is a location pointing to the buffer that we are fixing up. The kernel will then take care of fixing up the pointer to that buffer as well. Change-Id: I02417f28cff14688f2e1d6fcb959438fd96566cc Signed-off-by: Martijn Coenen <maco@google.com> Git-commit: d66d033983974c48ed375aa2503beb57347d23ac Git-repo: https://android.googlesource.com/kernel/common.git Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* | android: binder: split flat_binder_object.Martijn Coenen2017-11-141-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flat_binder_object is used for both handling binder objects and file descriptors, even though the two are mostly independent. Since we'll have more fixup objects in binder in the future, instead of extending flat_binder_object again, split out file descriptors to their own object while retaining backwards compatibility to existing user-space clients. All binder objects just share a header. Change-Id: If3c55f27a2aa8f21815383e0e807be47895e4786 Signed-off-by: Martijn Coenen <maco@google.com> Git-commit: ac07149f9cd19a747b967e81afe35199adafeb8b Git-repo: https://android.googlesource.com/kernel/common.git [resolved trivial merge conflicts] Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
* | Merge branch LA.BF64.1.2.3_rb1.17 into cm-14.1David Hays2017-11-112-5/+3
|\ \ | | | | | | | | | Change-Id: If5b9fe7dfb70d4e2172c86b05ed0480f9eaf3346
| * | ashmem: remove cache maintenance supportSudarshan Rajagopalan2017-04-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cache maintenance routines in ashmem were causing several security issues. Since they are not being used anymore by any drivers, its well to remove them entirely. CRs-Fixed: 1107034, 2001129, 2007786 Change-Id: I955e33d90b888d58db5cf6bb490905283374425b Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
| * | net: msm_rmnet: Add an IOCTL definition to deregister a net deviceRavinder Konka2016-10-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Platform drivers may be registered on driver startup for multiple channels which may cause probe and remove events to be called corresponding to driver events. It is possible that not all channels need to be enumerated for normal device operation. The unused channels also add unnecessary delay during sub system restart. Add an extended IOCTL which provides user space an option to unregister a platform driver. CRs-Fixed: 738039 Change-Id: Ifa6284563551ecdd297ae457ea2b35027f60844e Acked-by: Nagarjuna Chaganti <nchagant@qti.qualcomm.com> Signed-off-by: Ravinder Konka <rkonka@codeaurora.org> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
| * | Merge commit '1094ee8078f4ecf743690d2c1ddc117155051d64' into HEADPradosh Das2016-10-041-11/+13
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/gpu/msm/kgsl.c drivers/gpu/msm/kgsl_sharedmem.c drivers/misc/qcom/qdsp6v2/audio_amrwbplus.c drivers/net/wireless/cnss_prealloc/cnss_prealloc.c drivers/power/qcom/debug_core.c drivers/staging/android/ashmem.c drivers/thermal/msm_thermal-dev.c drivers/usb/core/hub.c sound/soc/msm/qdsp6v2/q6asm.c Change-Id: I02312ba5cacecaf9c467a06815d4a8fb32d43067 Signed-off-by: Pradosh Das <prados@codeaurora.org>
| | * | ASoC: msm: qdsp6v2: support multi-ch and samplerate > 48K for NT wmaWeiyin Jiang2016-07-081-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NT and compress offload wma mode are exercised, we need to implement changes in framework so that both have the same restrictions. Meanwhile, we will remove any limitation in driver to support multichannel and sample rate more than 48KHz wma playback in NT path. Add extra option to support default channel mapping for both back-speaker and side-speaker flavor. CRs-Fixed: 870824 Change-Id: I639fb29a880f774502c8b005577cd9c62162c30d Signed-off-by: Weiyin Jiang <wjiang@codeaurora.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-15 01:32:58 +0000