We're currently taking the upper 52 bits from the CB_PAR register and
using them for the output physical address. That doesn't make sense for
a few reasons, not the least of which is the fact that physical
addresses are only 48 bits on ARM64 and even less on ARM32. Also, when
using V7L and V8 descriptor formats the top byte of the CB_PAR register
contains the memory attributes for the translation. Fix this by masking
out everything above the valid physical address bits with PHYS_MASK.
Change-Id: I96096a6515dc42025d3134933a90b072e5153968
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We recently increased the maximum number of stream IDs from 8 to 16 in
[85fac623740fc: "iommu/arm-smmu: increase maximum stream ids"].
However, we can actually have many more than 16. Go ahead and increase
this limit to accomodate the maximum number of stream IDs as outlined in
the SMMUv2 spec.
Change-Id: I23cee7ad78f0d388e339a4c8a1058f0674f3edc3
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We support way more than 8 SIDs but currently error out if we get more
than that. Fix this.
Change-Id: I50e70b07ffbee783d3e6582fa7d9a175a1b26fe5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We currently don't check whether register_smmu_master while parsing the
device tree and adding device masters. Add error checking to facilitate
debugging and avoid probing of bogus devices.
Change-Id: I79c70d193c4705c21ea6a2e03ee048e7a4813b71
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we only program the VMID (in the CBAR register) for stage-2
context banks. The VMID is valid and often used in stage-1 context banks
as well. Program it in both cases.
Change-Id: Id4381e67f1c4c318c3137a5d56256af711491f08
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
dev_err already prints the device name. Remove the `dev_name(dev)' from
the print statement in arm_smmu_iova_to_phys_hard.
Change-Id: I5f5bcaf57349aba157789070e2f1441184ee62a6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently there could be races between different domains performing an
ATOS operation. Fix this by taking the domain lock around the ATOS.
Change-Id: I32e6e0a0c67ce82aff5abfc892098c684d399b2d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, we return garbage when iova_to_phys fails when we're using
hardware translation features (ATOS). iova_to_phys should return 0 when
it fails. Fix this.
Change-Id: I3bfefce7315e43a684c7c29c4fa7ef5960182ea8
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ARM SMMUs support memory access control via some bits in the translation
table descriptor memory attributes. Currently we assume all translations
are "unprivileged". Add support for privileged mappings, controlled by
the IOMMU_PRIV prot flag.
Also sneak in a whitespace change for consistency with nearby code.
Change-Id: I9d922c19d7dc8e64e07b216fc1bab373aa2e733d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some platforms require certain implementation-defined registers to be
programmed when first attaching to the SMMU. Add support for this via
specifying register offset, value pairs in the device tree.
Change-Id: Iac2fe42684c3849a24d0d1251a206954262257c5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Work around a hardware bug where some SMMUs cache invalid PTEs and mess
up the transaction logic. PTEs must be zero'd out completely rather than
just setting the last two bits to zero to work around this bug.
Change-Id: I98ac18142eda6f7817c78ab27a4850cdecf24913
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
We should avoid setting the ARM SMMU driver up as the IOMMU for the PCI
bus if there aren't any IOMMUs on the bus. Provide a Kconfig knob to
control this.
Change-Id: I748f689cd5f512aa7e45e146c6d7ddccadc47e44
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[pdaly@codeaurora.org Resolve minor conflicts]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
The ACTLR must be programmed according to the hardware design in order
for the coherent table walk feature to work on certain Qualcomm
hardware. Provide a new compatible string ("qcom,smmu-v2") to indicate
the relevant hardware and do the programming as needed.
Change-Id: I7e807384c821fc3d07274f35726abb28d0d75ee0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Under certain conditions coherent hardware translation table walks can
result in degraded performance. Add a new domain attribute to
disable/enable this feature in generic code along with the domain
attribute setter and getter to handle it in the ARM SMMU driver.
Change-Id: Ic9812d5047af19093ec2db8246a7f0f9ccb626ab
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Add a workaround for some buggy hardware that requires a TLB invalidate
operation to occur at map time. Activate the feature with the
qcom,smmu-invalidate-on-map boolean DT property.
Change-Id: I081a279fead983ae3d736b44cda371078e55a750
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Generic IOMMU device tree bindings were recently added in [bb1e25b9ed:
"devicetree: Add generic IOMMU device tree bindings"]. Implement the
bindings in the ARM SMMU driver.
See Documentation/devicetree/bindings/iommu/iommu.txt for the bindings
themselves.
Change-Id: I318b4cc347caccf3e142ce021057599eaea07814
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, we provide the iommu_ops.iova_to_phys service by doing a
table walk in software to translate IO virtual addresses to physical
addresses. On SMMUs that support it, it can be useful to ask the SMMU
itself to do the translation. This can be used to warm the TLBs for an
SMMU. It can also be useful for testing and hardware validation.
Since the address translation registers are optional on SMMUv2, only
enable hardware translations when using SMMUv1 or when SMMU_IDR0.S1TS=1
and SMMU_IDR0.ATOSNS=0, as described in the ARM SMMU v1-v2 spec.
Change-Id: I07157ced4b2d8a5974b69f84f0ba47ca1b99481b
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On some power-constrained platforms it's useful to disable power when a
device is not in use. Add support for specifying regulators for SMMUs
and only leave power on as long as the SMMU is in use (attached).
Change-Id: I87191d325423f160ddd4b71f5bf3a92f4942b821
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On some platforms with tight power constraints it is polite to only
leave your clocks on for as long as you absolutely need them. Currently
we assume that all clocks necessary for SMMU register access are always
on.
Add some optional device tree properties to specify any clocks that are
necessary for SMMU register access and turn them on and off as needed.
If no clocks are specified in the device tree things continue to work
the way they always have: we assume all necessary clocks are always
turned on.
Change-Id: Ie42647e117b51a45c939aa479487fa4b5f101c68
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In preparation for the forthcoming flurry of cherry-picks, match things
up with the 3.14 fork point by making the arm_smmu_ops variable
non-const. With this in place we should be able to cleanly cherry-pick
everything from the 3.14 fork point to the end of the msm-3.14 branch.
Change-Id: Ifa9d786e27be6d182edfecc1c05e033bc931cbd0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The memory to be mapped by the smmu needs to be uncached
since the bus is non-coherent. Pass coherent flag as false
to make sure that the memory is marked as uncached.
CRs-Fixed: 786121
Change-Id: Ie2849b1e1ec901e60e89706519cbd89d278e0b3e
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
IOMMU virtual addresses use the dma_addr_t type since they can be up to
64-bits. We're currently using an `unsigned int' to store our IOVA in
arm_iommu_map_sg, which could result in truncation. Use the correct
type for an I/O virtual address: dma_addr_t.
Change-Id: Ie63bf17268ca70d102ab9d472ed9bcc6f4a793d7
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In arm_iommu_map_sg, currently we map each individual link in the given
scatterlist into the SMMU individually such that they may or may not be
virtually contiguous. However, in most (all?) of our use cases we
actually want the entire sg list mapped into the SMMU as a single
contiguous range. Use iommu_map_range to accomplish this.
Change-Id: Icf72ece50c3120a0091dbfab1523ff11da20f807
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
dma_ops should be const since they shouldn't be changing after being
defined (there's even a checkpatch warning for this). Convert existing
dma_ops to const.
Change-Id: Ic27ba9a0832b12cae43cd45c72f053335845fd8f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Conflicts:
arch/arm64/include/asm/dma-mapping.h
arch/arm64/mm/dma-mapping.c
When CONFIG_ARM64_DMA_USE_IOMMU is not selected, drivers that make use
of the ARM DMA IOMMU mapping APIs currently don't link. First instinct
might be to add a dependency on CONFIG_ARM64_DMA_USE_IOMMU to those
drivers, but they might not actually want to do that because they might
have other ways of getting DMA-able memory.
Allow compilation when CONFIG_ARM64_DMA_USE_IOMMU is not selected by
providing necessary stub functions.
Change-Id: I172e00a0748c70676b8ff7555e217a1e6122e3e6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On systems with IOMMUs, it's useful to handle IOMMU mappings in the
dma-mapping layer. This is currently supported on arm but not arm64. Add
support in arm64 by gratuitously lifting most of the IOMMU-related stuff
from dma-mapping.c in arm.
The original arm work was done by Marek Szyprowski in [4ce63fcd91:
"ARM: dma-mapping: add support for IOMMU mapper"].
Change-Id: I1c3c8fe15049fe456751074398fd179ebd2ec64e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[pdaly@codeaurora.org Disable upstream implementation]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
It's incredibly useful to be able to see where reserved regions
were placed. Make those prints pr_info instead of just pr_debug.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Currently, the decision on which page protection to use
is limited to writecombine and coherent. Expand to include
strongly ordered memory and non consistent memory.
Change-Id: I7585fe3ce804cf321a5585c3d93deb7a7c95045c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Reset the following files:
arm-smmu.c
iommu.c
include/linux/iommu.h
include/trace/events/iommu.h
to the git merge base between 3.18 and 4.4:
b2776bf714
Change-Id: I9aa58e08125e3a72d1e9742e26d4a6fab34b0ed5
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Move qpnp-power-on driver as input driver, also update
regulator related api in order to accomodate regualtor
framework
Signed-off-by: Jigarkumar Kishorkumar Zala <j_zala@codeaurora.org>
Dummy release event is sent when system resumes. This behavior
makes long press detection failed for some keys like POWER key
and HEADSET key. Add INPUT_PROP_NO_DUMMY_RELEASE to make it is
possible for some input to avoid this behavior.
Need add set_bit(INPUT_PROP_NO_DUMMY_RELEASE,inputdevice->propbit)
in specific drivers that don't want the DUMMY release event.
Change-Id: I30ba5045273aca9a4613b7f6dcdcf7a7173b5c27
Signed-off-by: Kun Liang <kunliang@codeaurora.org>
[joshc: Renumbered flag due to conflict, adapted to upstream
input_reset_device() changes upstream.]
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
[abhimany: Renumbered flag due to conflict]
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
The status of the CoreSight fuses can be derived from the AUTHSTATUS
register. This patch add support to read AUTHSTATUS, which could be used
by Coresight device drivers to determine if that component is functional
in hardware.
Change-Id: I6b7ac2a3558c238ac5fca452ddfb6c88eef14b8b
Signed-off-by: Shashank Mittal <mittals@codeaurora.org>
PMIC VADC_TM driver provides clients to set
threholds on supported VADC channels such as
vph_pwr and thermistors and receive notification
on threshold crossing.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
QPNP PMIC VADC driver provides clients ability
to read voltage channels supported by the PMIC such
as vph_pwr and board thermistors.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
This snapshot is taken as of msm-3.18 commit dbdb6776f
(Merge "msm: camera: Add dummy sub module in sensor pipeline")
Fixup compilation to support int type for temperature
value as part of thermal ops API upgrade.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
SCM (Secure Channel Manager) driver is used to communicate
with the secure world entities like trustzone and hypervisor.
As a part of the communication we expect to give certain
input, output operands and the caller of the scm_callX
API would expect that output values or return values
of the scm_callX should not get corrupted (if they depend on it).
Due to Kasan instrumentation of the SCM driver following
code is getting instrumented with Kasan __asan_store8_noabort
APIs which would internally check if the memory access is allowed
and it is the functionality of the Kasan to check/instrument
the load and stores.
if (ret1)
*ret1 = r1;
if (ret2)
*ret2 = r2;
if (ret3)
*ret3 = r2;
All will be fine for the first *ret1 = r1; execution since
GCC has generated the code which saves the x1 value (r1)
into the another register but the execution of the
__asan_store8_noabort API after the saving of the register
corrupts the x2 and x3 when it returns. GCC has no knowledge
at this point to save the x2 and x3.
Due to this x2 and x3 is loaded with the Kasan shadow
offset value and Kasan shifted (>> 3) address.
Since x2 and x3 (r2 and r3 in the code above) would be used
as the ret2 and ret3 for the caller of the scm_callX API
the caller would get the wrong return values (if it needs them).
QSEECOM is one such driver which uses these ret2 and ret3 values
and due to this corruption QSEECOM driver was treating it as
SCM call failure, though the bug described above due to Kasan
instrumentation would be applicable to any caller needing
the right values of the ret2 and ret3.
SCM driver is very small and simple and we would not expect
the Out of bound or use-after-free errors for it, so it would
be fine to skip it from the Kasan instrumentation.
Change-Id: I8b2a17759295375c21abc520110f855f349faf4b
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Allow enabling KASAN on a per-directory or per-file basis rather than
for the entire kernel.
Change-Id: I9a491d3ab0df4c42302a258b9edb3b78cf4e1db0
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Some functions consume more than allowed stack frame
size with KASan enabled and GCC warns it as an error.
To avoid compilation warning, allow larger stack frame
size when KASan is enabled instead of changing each file.
Below is one of the warning messages for reference.
kernel/net/wireless/nl80211.c: In function 'nl80211_send_wiphy':
kernel/net/wireless/nl80211.c:1705:1: warning: the frame size
of 5488 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Change-Id: I953018f459bf048366f0ba5ff7c980edcd9bbe07
Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
KASan marks slub objects as redzone and free and the bitmasks for
that region are not cleared until the pages are freed. When
CONFIG_PAGE_POISONING is enabled, as the pages still have special
bitmasks, KAsan report arises during pages poisoning. So mark the
pages as alloc status before poisoning the pages.
==================================================================
BUG: KASan: use after free in memset+0x24/0x44 at addr ffffffc0bb628000
Write of size 4096 by task kworker/u8:0/6
page:ffffffbacc51d900 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
Call trace:
[<ffffffc00008c010>] dump_backtrace+0x0/0x250
[<ffffffc00008c270>] show_stack+0x10/0x1c
[<ffffffc001b6f9e4>] dump_stack+0x74/0xfc
[<ffffffc0002debf4>] kasan_report_error+0x2b0/0x408
[<ffffffc0002dee28>] kasan_report+0x34/0x40
[<ffffffc0002de240>] __asan_storeN+0x15c/0x168
[<ffffffc0002de47c>] memset+0x20/0x44
[<ffffffc0002d77bc>] kernel_map_pages+0x2e8/0x384
[<ffffffc000266458>] free_pages_prepare+0x340/0x3a0
[<ffffffc0002694cc>] __free_pages_ok+0x20/0x12c
[<ffffffc00026a698>] __free_pages+0x34/0x44
[<ffffffc00026ab3c>] __free_kmem_pages+0x8/0x14
[<ffffffc0002dc3fc>] kfree+0x114/0x254
[<ffffffc000b05748>] devres_free+0x48/0x5c
[<ffffffc000b05824>] devres_destroy+0x10/0x28
[<ffffffc000b05958>] devm_kfree+0x1c/0x3c
Memory state around the buggy address:
ffffffc0bb627f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0bb627f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc0bb628000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffffffc0bb628080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffffffc0bb628100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
BUG: KASan: use after free in memset+0x24/0x44 at addr ffffffc0bb2fe000
Write of size 4096 by task swapper/0/1
page:ffffffbacc4fdec0 count:0 mapcount:0 mapping: (null) index:0xffffffc0bb2fe6a0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
Call trace:
[<ffffffc00008c010>] dump_backtrace+0x0/0x250
[<ffffffc00008c270>] show_stack+0x10/0x1c
[<ffffffc001b6f9e4>] dump_stack+0x74/0xfc
[<ffffffc0002debf4>] kasan_report_error+0x2b0/0x408
[<ffffffc0002dee28>] kasan_report+0x34/0x40
[<ffffffc0002de240>] __asan_storeN+0x15c/0x168
[<ffffffc0002de47c>] memset+0x20/0x44
[<ffffffc0002d77bc>] kernel_map_pages+0x2e8/0x384
[<ffffffc000266458>] free_pages_prepare+0x340/0x3a0
[<ffffffc0002694cc>] __free_pages_ok+0x20/0x12c
[<ffffffc00026a698>] __free_pages+0x34/0x44
[<ffffffc0002d9c98>] __free_slab+0x15c/0x178
[<ffffffc0002d9d14>] discard_slab+0x60/0x6c
[<ffffffc0002dc034>] __slab_free+0x320/0x340
[<ffffffc0002dc224>] kmem_cache_free+0x1d0/0x25c
[<ffffffc0003bb608>] kernfs_put+0x2a0/0x3d8
Memory state around the buggy address:
ffffffc0bb2fdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc0bb2fdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffc0bb2fe000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc
^
fffffc0bb2fe080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc0bb2fe100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Change-Id: Id963b9439685f94a022dcdd60b59aaf126610387
Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
[satyap: trivial merge conflict resolution]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
the pages allocated for thread info is used for stack. KAsan marks
some stack memory region for guarding area and the bitmasks for
that region are not cleared until the pages are freed. When
CONFIG_PAGE_POISONING is enabled, as the pages still have special
bitmasks, a out of bound access KASan report arises during pages
poisoning. So mark the pages as alloc status before poisoning the
pages.
==================================================================
BUG: KASan: out of bounds on stack in memset+0x24/0x44 at addr ffffffc0b8e3f000
Write of size 4096 by task swapper/0/0
page:ffffffbacc38e760 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.18.0-g5a4a5d5-07244-g488682c-dirty #12
Hardware name: Qualcomm Technologies, Inc. MSM 8996 v2.0 LiQUID (DT)
Call trace:
[<ffffffc00008c010>] dump_backtrace+0x0/0x250
[<ffffffc00008c270>] show_stack+0x10/0x1c
[<ffffffc001b6f9e4>] dump_stack+0x74/0xfc
[<ffffffc0002debf4>] kasan_report_error+0x2b0/0x408
[<ffffffc0002dee28>] kasan_report+0x34/0x40
[<ffffffc0002de240>] __asan_storeN+0x15c/0x168
[<ffffffc0002de47c>] memset+0x20/0x44
[<ffffffc0002d77bc>] kernel_map_pages+0x2e8/0x384
[<ffffffc000266458>] free_pages_prepare+0x340/0x3a0
[<ffffffc0002694cc>] __free_pages_ok+0x20/0x12c
[<ffffffc00026a698>] __free_pages+0x34/0x44
[<ffffffc00026abb0>] free_kmem_pages+0x68/0x80
[<ffffffc0000b0424>] free_task+0x80/0xac
[<ffffffc0000b05a8>] __put_task_struct+0x158/0x23c
[<ffffffc0000b9194>] delayed_put_task_struct+0x188/0x1cc
[<ffffffc00018586c>] rcu_process_callbacks+0x6cc/0xbb0
[<ffffffc0000bfdb0>] __do_softirq+0x368/0x750
[<ffffffc0000c0630>] irq_exit+0xd8/0x15c
[<ffffffc00016f610>] __handle_domain_irq+0x108/0x168
[<ffffffc000081af8>] gic_handle_irq+0x50/0xc0
Memory state around the buggy address:
ffffffc0b8e3f980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0b8e3fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc0b8e3fa80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
^
ffffffc0b8e3fb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0b8e3fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Change-Id: I90aa1c6e82a0bde58d2d5d68d84e67f932728a88
Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
The commit 'a106f65b("dma-mapping: Add dma_remap functions")' is
defined remap functions for ARM arch only, so it will break other
architecture compilation.
So remap functions are excluded, if arch is not using DMA.
Change-Id: Id39fcbac74f30a0ab1b3ce0c780460017ea189e5
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
This property is no longer used in 4.4 kernel, hence remove it.
Change-Id: I8fe311d95359220fa8f44e9b39db61e01ee34f5b
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
This is handled in the ufs platform init. Drop the upstream
change that was missed in the ufs driver port to 4.4 kernel.
Change-Id: Ia3305f2b4f6c6eeafe3866833f2c98e186ad6632
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Enable the following MSM I2C related features:
- qcom-sps-dma driver which is the dma engine wrapper for BAM
- i2c-msm-v2 driver, the main MSM I2C driver.
- I2C CHARDEV that allows userspace to communicate with I2C framework.
Change-Id: Ibca06d935de61517ef1a927828789875fcdb7718
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
