This patch allows the administrator to configure the interface
name of a function using u_ether (e.g., eem, ncm, rndis).
Currently, all such interfaces, regardless of function type, are
always called usb0, usb1, etc. This makes it very cumbersome to
use more than one such type at a time, because userspace cannnot
easily tell the interfaces apart and apply the right
configuration to each one. Interface renaming in userspace based
on driver doesn't help, because the interfaces all have the same
driver. Without this patch, doing this require hacks/workarounds
such as setting fixed MAC addresses on the functions, and then
renaming by MAC address, or scraping configfs after each
interface is created to find out what it is.
Setting the interface name is done by writing to the same
"ifname" configfs attribute that reports the interface name after
the function is bound. The write must contain an interface
pattern such as "usb%d" (which will cause the net core to pick
the next available interface name starting with "usb").
This patch does not allow writing an exact interface name (as
opposed to a pattern) because if the interface already exists at
bind time, the bind will fail and the whole gadget will fail to
activate. This could be allowed in a future patch.
For compatibility with current userspace, when reading an ifname
that has not currently been set, the result is still "(unnamed
net_device)". Once a write to ifname happens, then reading ifname
will return whatever was last written.
Tested by configuring an rndis function and an ncm function on
the same gadget, and writing "rndis%d" to ifname on the rndis
function and "ncm%d" to ifname on the ncm function. When the
gadget was bound, the rndis interface was rndis0 and the ncm
interface was ncm0.
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
(cherry picked from commit 63d152149bhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Link: https://lore.kernel.org/r/20210113234222.3272933-1-lorenzo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Change-Id: I04deb6cc1d8a5b8ee82404940de2a79c06fbafe7
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit e5383432d9 ("scsi: ufs: Clear UAC for FFU and RPMB LUNs") in -stable
merge, wrong code was added back.
Let's fix it.
Fixes: 7eadb0006a ("Merge 5.10.7 into android12-5.10")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I69c8dee273194279bc7bc23f199f0ecb0e617d03
We have to start somewhere, so add initial abi_gki_aarch64.xml file
for the current snapshot with a limited set of symbols.
Note, these symbols have not been reviewed yet, it just gives us a base
to work off of, as now the infrastructure allows for building and
managing the .xml file properly.
Bug: 177417361
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic9d9aeead1f017409644810f50528be2d165bae6
In the Scudo memory allocator [1] we would like to be able to detect
use-after-free vulnerabilities involving large allocations by issuing
mprotect(PROT_NONE) on the memory region used for the allocation when it
is deallocated. Later on, after the memory region has been "quarantined"
for a sufficient period of time we would like to be able to use it for
another allocation by issuing mprotect(PROT_READ|PROT_WRITE).
Before this patch, after removing the write protection, any writes to the
memory region would result in page faults and entering the copy-on-write
code path, even in the usual case where the pages are only referenced by a
single PTE, harming performance unnecessarily. Make it so that any pages
in anonymous mappings that are only referenced by a single PTE are
immediately made writable during the mprotect so that we can avoid the
page faults.
This program shows the critical syscall sequence that we intend to use in
the allocator:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
for (int i = 0; i != 100000; ++i) {
memset(addr, i, kSize);
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
The effect of this patch on the above program was measured on a
DragonBoard 845c by taking the median real time execution time of 10 runs.
Before: 3.19s
After: 0.79s
The effect was also measured using one of the microbenchmarks that
we normally use to benchmark the allocator [2], after modifying it
to make the appropriate mprotect calls [3]. With an allocation size
of 131072 bytes to trigger the allocator's "large allocation" code
path the per-iteration time was measured as follows:
Before: 33364ns
After: 6886ns
This patch means that we do more work during the mprotect call itself
in exchange for less work when the pages are accessed. In the worst
case, the pages are not accessed at all. The effect of this patch in
such cases was measured using the following program:
#include <string.h>
#include <sys/mman.h>
enum { kSize = 131072 };
int main(int argc, char **argv) {
char *addr = (char *)mmap(0, kSize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
memset(addr, 1, kSize);
for (int i = 0; i != 100000; ++i) {
#ifdef PAGE_FAULT
memset(addr + (i * 4096) % kSize, i, 4096);
#endif
mprotect((void *)addr, kSize, PROT_NONE);
mprotect((void *)addr, kSize, PROT_READ | PROT_WRITE);
}
}
With PAGE_FAULT undefined (0 pages touched after removing write
protection) the median real time execution time of 100 runs was measured
as follows:
Before: 0.325928s
After: 0.365493s
With PAGE_FAULT defined (1 page touched) the measurements were
as follows:
Before: 0.441516s
After: 0.380251s
So it seems that even with a single page fault the new approach is faster.
I saw similar results if I adjusted the programs to use a larger mapping
size. With kSize = 1048576 I get these numbers with PAGE_FAULT undefined:
Before: 1.563078s
After: 1.607476s
i.e. around 3%.
And these with PAGE_FAULT defined:
Before: 1.684663s
After: 1.683272s
i.e. about the same.
What I think we may conclude from these results is that for smaller
mappings the advantage of the previous approach, although measurable, is
wiped out by a single page fault. I think we may expect that there should
be at least one access resulting in a page fault (under the previous
approach) after making the pages writable, since the program presumably
made the pages writable for a reason.
For larger mappings we may guesstimate that the new approach wins if the
density of future page faults is > 0.4%. But for the mappings that are
large enough for density to matter (not just the absolute number of page
faults) it doesn't seem like the increase in mprotect latency would be
very large relative to the total mprotect execution time.
Link: https://lkml.kernel.org/r/20201230004134.1185017-1-pcc@google.com
Link: https://linux-review.googlesource.com/id/I98d75ef90e20330c578871c87494d64b1df3f1b8
Link: [1] https://source.android.com/devices/tech/debug/scudo
Link: [2] https://cs.android.com/android/platform/superproject/+/master:bionic/benchmarks/stdlib_benchmark.cpp;l=53;drc=e8693e78711e8f45ccd2b610e4dbe0b94d551cc9
Link: [3] https://github.com/pcc/llvm-project/commit/scudo-mprotect-secondary
Signed-off-by: Peter Collingbourne <pcc@google.com>
Cc: Kostya Kortchinsky <kostyak@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit 2a9e75c907fa2de626d77dd4051fc038f0dbaf52
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Bug: 135772972
Change-Id: I98d75ef90e20330c578871c87494d64b1df3f1b8
Code added for cpu pause feature should be conditional based on
CONFIG_SUSPEND
Fixes: 5ada76d056 ("ANDROID: sched/pause: prevent wake up paused cpus")
Bug: 161210528
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I8dc31064bafb31dd570daae97b7bb547384a771f
Vendor hooks required explicitly defining macros or inline functions
to handle the non-GKI build case (!CONFIG_ANDROID_VENDOR_HOOKS). Added
support for generating them automatically so the macros are no longer
required.
Both models are now supported so we can transition.
Bug: 177416721
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I01acc389d315a5d509b0c48116854342a42e1058
Fixes use of %p format for u64 (should be %llx)
Fixes: e091aa59b9 ("ANDROID: tracing: Add register read and write
tracing support")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I4cd3a179e08a3fb682db6d9bb8530d504eb71720
CFI has additional overhead on indirect branches to modules as the
target is not known at kernel compile-time. This has been demonstrated
to cause problematic performance regressions on benchmarks using GKI
together with modularized scheduler callbacks attached to restricted
vendor hooks.
To restore some of the performance back, let's disable CFI around the
restricted hook call sites and issue a raw indirect call in fast paths.
We should be able to drop this patch when/if the arm64 static_call
port lands upstream [1] as this would make tracepoints circumvent some
of the CFI checks using text patching, but that still remain to be
proven.
[1] https://lore.kernel.org/linux-arm-kernel/20201028184114.6834-1-ardb@kernel.org/
Bug: 168521642
Change-Id: I7cd59f582b12fed15be64059f08122f96786e650
Signed-off-by: Quentin Perret <qperret@google.com>
e820__mapped_all() is passed as a callback to is_mmconf_reserved(),
which expects a function of type:
typedef bool (*check_reserved_t)(u64 start, u64 end, unsigned type);
However, e820__mapped_all() accepts enum e820_type as the last argument
and this type mismatch trips indirect call checking with Clang's
Control-Flow Integrity (CFI).
As is_mmconf_reserved() only passes enum e820_type values for the
type argument, change the typedef and the unused type argument in
is_acpi_reserved() to enum e820_type to fix the type mismatch.
Bug: 145210207
Change-Id: Ic7d0f28887e44c40d09e2392c4301547e642a294
(cherry picked from commit 83321c335d)
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201130193900.456726-1-samitolvanen@google.com
Disable CFI for the stand-alone purgatory.ro.
Bug: 145210207
Change-Id: I957fd1d000ed27ca9fe9adb6c0ec2b6e0f6d73ce
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
optprobe_template_func is not marked as a global symbol, which
conflicts with the C declaration and confuses LLVM when CFI is
enabled. However, marking the symbol global results in a CFI jump
table entry being generated for it, which makes objtool unhappy as the
jump table contains a jump to .rodata.
This change solves both issues by removing the C reference to
optprobe_template_func and generates the STACK_FRAME_NON_STANDARD
entry in inline assembly instead.
Bug: 145210207
Change-Id: Ib19b86cf437277036fa218d6e8d7292f10bef940
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Allow CFI enabled entry code to make indirect calls by also mapping
CFI jump tables, and add a check to ensure the jump table section is
not empty.
Bug: 145210207
Change-Id: I4ad3506f7a365cd068009348d45b54e228e42e33
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Also ignore these relocations when loading modules.
Bug: 145210207
Change-Id: I53c8ed4811fee4b770fc5824376fef657ab47bdf
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The __typeid__* symbols aren't actually relocations, so they can be
ignored during relocation generation.
Bug: 145210207
Change-Id: Ib9abe21c3c2aeee2a41491f8358f1a88717fa843
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Instead of using inline asm for the int3 selftest (which confuses the
Clang's ThinLTO pass), this restores the C function but disables KASAN
(and tracing for good measure) to keep the things simple and avoid
unexpected side-effects. This attempts to keep the fix from commit
ecc6061038 ("x86/alternatives: Fix int3_emulate_call() selftest stack
corruption") without using inline asm.
Bug: 145210207
Change-Id: Ib4cdfde61473febd867c2329f57ec9a8a5eced2f
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The exception table entries are constructed out of a relative offset
and point to the actual function, not the CFI table entry. For now,
just mark the caller as not checking CFI. The failure is most visible
at boot with CONFIG_DEBUG_RODATA_TEST=y.
Bug: 145210207
Change-Id: Idf6efed424fc95ef20ddd69596478dc813754ce4
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Older versions of Clang didn't generate BTI instructions for the
compiler-generated CFI check functions. As CFI provides a more
fine-grained control-flow checking then BTI, disable BTI when CFI is
enabled and we're using Clang <12.
Bug: 145210207
Change-Id: I248bc761443e4f354cf4dfbfc3db0fc22385ce63
Link: https://bugs.llvm.org/show_bug.cgi?id=46258
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Disable LTO+CFI for code that runs at EL2 to avoid address space
confusion as the CFI jump tables point to EL1 addresses.
Bug: 145210207
Change-Id: I81359ec648b2616e85dfd3bb399327bac980b3fe
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
__apply_alternatives makes indirect calls to functions whose address is
taken in assembly code using the alternative_cb macro. With CFI enabled
using non-canonical jump tables, the compiler isn't able to replace the
function reference with the jump table reference, which trips CFI.
Bug: 145210207
Change-Id: I2361b601d987cd25f88aa0b9f37b400ff566febc
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
We use non-canonical CFI jump tables with CONFIG_CFI_CLANG, which
means the compiler replaces function address references with the
address of the function's CFI jump table entry. This results in
__pa_symbol(function), for example, returning the physical address
of the jump table entry, which can lead to address space confusion
since the jump table itself points to a virtual address. The same
issue happens when passing function pointers to hypervisor code
running at EL2.
This change adds __va_function and __pa_function macros, which use
inline assembly to take the actual function address instead, and
changes the relevant code to use these macros.
Bug: 145210207
Change-Id: Ie3079c10427bde705a2244cfb3cb5fb954e5e065
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Disable CFI checking for functions that switch to linear mapping and
make an indirect call to a physical address, since the compiler only
understands virtual addresses.
Bug: 145210207
Change-Id: I2bd39c5891d4f2ce033e5ee515cf86d96eb0447f
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
To ensure we take the actual address of a function in kernel text,
use __va_function. Otherwise, with CONFIG_CFI_CLANG, the compiler
may replace the address with a pointer to the CFI jump table, which
can reside inside the module, when compiled with CONFIG_LKDTM=m.
Bug: 145210207
Change-Id: Ie65d3aace55695a5e515436267c048b13ace9002
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Casting the comparison function to a different type trips indirect call
Control-Flow Integrity (CFI) checking. Remove the additional consts from
cmp_func, and the now unneeded casts.
Bug: 145210207
Change-Id: Iffe0eeec8e7f65a5937513a4bb87e5107faa004e
Link: https://lore.kernel.org/lkml/20200110225602.91663-1-samitolvanen@google.com/
Fixes: 043b3f7b63 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
BPF dispatcher functions are patched at runtime to perform direct
instead of indirect calls. Disable CFI for the dispatcher functions
to avoid conflicts.
Bug: 145210207
Change-Id: Iea72f5a9fe09dd5adbb90b0174945707f42594b0
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With ThinLTO and CFI both enabled, LLVM appends a hash to the
names of all static functions. This breaks userspace tools, so
strip out the hash from output.
Bug: 145210207
Change-Id: Icc0173f1d754b378ae81a9f91d84c0814ba26b78
Suggested-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With CFI, a callback function passed to __kthread_queue_delayed_work
from a module can point to a jump table entry defined in the module
instead of the one used in the core kernel, which breaks this test:
WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn);
To work around the problem, disable the warning when CFI and modules
are both enabled.
Bug: 145210207
Change-Id: I5b0a60bb69ce8e2bc0d8e4bf6736457b6425b6cf
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With CFI, a callback function passed to __queue_delayed_work from a
module can point to a jump table entry defined in the module instead
of the one used in the core kernel, which breaks this test:
WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
To work around the problem, disable the warning when CFI and modules
are both enabled.
Bug: 145210207
Change-Id: I2a631ea3da9e401af38accf1001082b93b9b3443
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With -ffunction-sections, Clang can generate a jump beyond the end of a
section when the section ends in an unreachable instruction. If the
offset matches the section length, use the last instruction as the jump
destination.
Bug: 145210207
Change-Id: I422b805fe0e857915f0726404d14f62c01629849
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Skip checking for the compiler-generated jump table symbols when Clang's
Control-Flow Integrity (CFI) is enabled.
Bug: 145210207
Change-Id: Icd1fad50214016348289ac5980b062708ab9ecd0
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With CONFIG_CFI_CLANG, LLVM replaces function references with CFI
jump table addresses to allow type checking with indirect calls. This is
unnecessary in ksymtab, so this change uses inline assembly to emit
ksymtab entries that point to the actual function instead when CFI is
enabled.
Bug: 145210207
Change-Id: I894af2c7df476eb00d656c7692a33b25de31e26d
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
On modules with no executable code, LLVM generates a __cfi_check stub,
but won't align it to page size as expected. This change ensures the
function is at the beginning of the .text section and correctly aligned
for the CFI shadow.
Also discard the .eh_frame section, which LLD may emit with CFI_CLANG.
Bug: 145210207
Change-Id: I08923febb549aa64454282cc864ac80dadd717b9
Link: https://bugs.llvm.org/show_bug.cgi?id=46293
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
We use non-canonical CFI jump tables with CONFIG_CFI_CLANG, which
means the compiler replaces function address references with the
address of the function's CFI jump table entry. This results in
__pa_symbol(function), for example, returning the physical address
of the jump table entry, which can lead to address space confusion
since the jump table itself points to a virtual address.
This change adds generic definitions for __pa/va_function, which
architectures that support CFI can override.
Bug: 145210207
Change-Id: I5b616901d5582478df613a4d28bf2b9c911edb46
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With non-canonical CFI, the compiler rewrites function references to
point to the CFI jump table for indirect call checking. This won't
happen when the address is taken in assembly, and will result in a CFI
failure if we jump to the address later in C code.
This change adds the __cficanonical attribute, which tells the
compiler to switch to a canonical jump table for the function. With
canonical CFI, the compiler appends a .cfi postfix to the function
name, and points the original symbol to the jump table. This allows
addresses taken in assembly code to be used for indirect calls without
tripping CFI checks.
Bug: 145210207
Change-Id: Iaca9d1d95f59d7169168d89bc10bf71420487a67
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds the CONFIG_CFI_CLANG option, CFI error handling,
and a faster look-up table for cross module CFI checks.
Bug: 145210207
Change-Id: I68d620ca548a911e2f49ba801bc0531406e679a3
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Bug: 177075428
Test: incfs_test passes
atest GtsIncrementalInstallTestCases has only 8 failures
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I73accfc1982aec1cd7947996c25a23e4a97cfdac
.blocks_writen file handling was missing some operations:
SELinux xattr handlers, safety checks for it being a
pseudo file etc.
This CL generalizes pseudo file handling so that all such
files work in a generic way and next time it should be
easier to add all operations at once.
Bug: 175823975
Test: incfs_tests pass
Change-Id: Id2b1936018c81c62c8ab4cdbaa8827e2679b513f
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
When a buffer is added to the LRU list, a reference is taken which is
not dropped until the buffer is evicted from the LRU list. This is the
correct behavior, however this LRU reference will prevent the buffer
from being dropped. This means that the buffer can't actually be dropped
until it is selected for eviction. There's no bound on the time spent
on the LRU list, which means that the buffer may be undroppable for
very long periods of time. Given that migration involves dropping
buffers, the associated page is now unmigratible for long periods of
time as well. CMA relies on being able to migrate a specific range
of pages, so these types of failures make CMA significantly
less reliable, especially under high filesystem usage.
Rather than waiting for the LRU algorithm to eventually kick out
the buffer, explicitly remove the buffer from the LRU list when trying
to drop it. There is still the possibility that the buffer
could be added back on the list, but that indicates the buffer is
still in use and would probably have other 'in use' indicates to
prevent dropping.
Note: a bug reported by "kernel test robot" lead to a switch from
using xas_for_each() to xa_for_each().
Bug: 174118021
Link: https://lore.kernel.org/linux-mm/cover.1610572007.git.cgoldswo@codeaurora.org/
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Matthew Wilcox <willy@infradead.org>
Reported-by: kernel test robot <oliver.sang@intel.com>
Change-Id: I4a93c4ed81c57874764d12f3beea1194a30c13b2
In order to debug critical domain and device power issues, it may be
necessary to disallow certain idle states at runtime. Enable a vendor
hook to check if a domain idle state is allowed for powering down the
domain.
Bug: 175718935
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Change-Id: I403c0c7d272439fb338bbf54a346861559385047
Previously idle_cpu is exported which is used by vendor module to check
if a cpu is in idle state, but later we think available_idle_cpu is
better than idle_cpu because it also checks vcpu_is_preempted.
Bug: 171740453
Change-Id: I17ccc4925650431f334a9eb2bbc94a138ab36ae0
Signed-off-by: Rick Yiu <rickyiu@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
If CONFIG_LOCKDEP is enabled, export sched_domains_mutex as it is
indirectly accessed by the macro for_each_domain, and that macro might
be used in module code.
Bug: 176254015
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Change-Id: Ia9f2989de41b2224c63855f2fd129cbeeac4f195
Signed-off-by: Will McVicker <willmcvicker@google.com>
IOMMU_SYS_CACHE_ONLY_NWA allows buffers for non-coherent devices
to be mapped with the correct memory attributes so that the buffers
can be cached in the system cache, with a no write allocate cache policy.
However, this property is only usable by drivers that invoke the
IOMMU API directly; it is not usable by drivers that use the DMA API.
Thus, introduce DMA_ATTR_SYS_CACHE_ONLY_NWA, so that drivers for
non-coherent devices that use the DMA API can use it to specify if
they want a buffer to be cached in the system cache.
Bug: 176778547
Change-Id: Ic812a1fb144a58deb4279c2bf121fc6cc4c3b208
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
IOMMU_SYS_CACHE_ONLY allows buffers for non-coherent devices
to be mapped with the correct memory attributes so that the buffers
can be cached in the system cache. However, this property
is only usable by drivers that invoke the IOMMU API directly;
it is not usable by drivers that use the DMA API.
Thus, introduce DMA_ATTR_SYS_CACHE_ONLY, so that drivers for
non-coherent devices that use the DMA API can use it to specify if
they want a buffer to be cached in the system cache.
Bug: 176778547
Change-Id: I849d7a3f36b689afd2f6ee400507223fd6395158
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Non-coherent devices on systems that support a system or
last level cache may want to request that allocations be
cached in the system cache. For memory that is allocated
by the kernel, and used for DMA with devices, the memory
attributes used for CPU access should match the memory
attributes that will be used for device access.
The memory attributes that need to be programmed into
the MAIR for system cache usage are:
0xf4 - Normal memory, outer write back read/write allocate,
inner non-cacheable.
There is currently no support for this memory attribute for
CPU mappings, so add it.
Bug: 176778547
Change-Id: I3abc7becd408f20ac5499cbbe3c6c6f53f784107
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
