* quic/dev/msm-4.14-display:
drm/msm/dp: clear HDR data for each session
drm/msm/sde: Send blank notification only when CRTC active changed
drm/msm/sde: allow PP buffer overflow irq disable after encoder disable
drm/msm: export symbols for drm client registration API
drm/msm/dp: complete link training before hot plug notification
drm/msm/sde: prevent null pointer access on disabled encoder
drm/msm/sde: manage sde pm_qos vote through atomic counter
drm/msm/sde: fix out of bounds memory access in sde kms
drm/msm: avoid memory allocation when sgt is imported
Change-Id: I5d2dd5bc966875d05e717719ac62633b8106a033
Signed-off-by: Namratha Siddappa <namratha@codeaurora.org>
Enable the device-mapper target "dm-default-key" which assigns
an encryption key to bios that don't already have one. This will
be used on Android's userdata partition, so that all data not
already encrypted with ext4 encryption is still encrypted with a
default key.
Change-Id: If6ef872019b1ae489ff1122a56ced0917a9aae85
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
commit 2b425b7413e2 ("dm-default-key, f2fs, ICE: support dm-default-key with f2fs/ICE")
supports bio->bi_crypt_skip, so this patch should address the original issue by
adding this condition.
Change-Id: I215cd9d02e364af07eebf388000809cdf0cce472
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
This patch fixes assigning bi_crypt_key for moving data which was previously
encrypted by f2fs.
Note that, dm-default-key should not assign bi_crypt_key, if bi_crypt_skip is
set.
The bug sceanrios is:
1. write data with user key by f2fs
- ENC(KU, IVU, DATA)
2. log out user key
3. read data #1 w/o user key from LBA #a
4. dm-default-key assigns default key
- DEC(KD, LBA#a, ENC(KU, IVU, DATA))
5. write data #1 w/o user key into LBA #b
6. dm-default-key assigns default key
- ENC(KD, LBA#b, DEC(KD, LBA#a, ENC(KU, IVU, DATA)))
7. Read DATA out with valid logged-in user key
- DEC(KU, IVU, ENC(KD, LBA#b, DEC(KD, LBA#a, ENC(KU, IVU, DATA))))
So, this patch introduces bi_crypt_skip to avoid 4. ~ 6 with right flow:
1. write data with user key by f2fs
- ENC(KU, IVU, DATA)
2. log out user key
3. read data #1 w/o user key from LBA #a
4. dm-default-key skip to assign default key
- ENC(KU, IVU, DATA)
5. write data #1 w/o user key into LBA #b
6. dm-default-key skips to assign default key
- ENC(KU, IVU, DATA)
7. Try to read DATA with valid logged-in user key
- DEC(KU, IVU, ENC(KU, IVU, DATA))
Bug: 68721442
Change-Id: Icefe85f608b7c3c84beb2bfa4267efd0f3787453
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
If all targets in a device-mapper table support inline encryption, mark
the mapped device as supporting inline encryption. This will allow
filesystems such as ext4 to tell whether the hardware supports inline
encryption even in the case where there is an intervening dm device.
Change-Id: I596829f6c5a39fb0d5bedfac9f18828ae27444cb
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
Add a device-mapper target "dm-default-key" which assigns an encryption
key to bios that don't already have one. This will be used on Android's
userdata partition, so that all data not already encrypted with ext4
encryption is still encrypted with a default key (which will not be
derived from a user credential but will still be protected in some way).
Currently this feature depends on inline encryption support in hardware
via Qualcomm ICE; no software fallback is implemented yet.
An alternate approach considered was to introduce a block device ioctl
which would associate an encryption key with a struct block_device,
which would then be used as the default for bios issued to that
block_device. However, that approach had some issues which made the dm
target seem like the better solution, and perhaps more likely to be
accepted upstream in some form someday (at least, once we have
vendor-independent inline encryption support upstream). Specifically:
1.) The struct block_device for a partition really only represents a
part of some underlying disk along with some state associated with
its current users. Notably, the block_device for a given partition
is not guaranteed to stay around while no one has it opened or
mounted. This means that any extra state like an encryption key we
may try to tie a block_device can be lost if there is a period of
time when no one is using the block device. Granted, this can't
happen while the filesystem on the device is mounted, and it also
can't happen on systems that use tmpfs for their /dev because the
block_device will be pinned by the device node. But either way, a
dm target does not have this problem.
2.) The block_device for a partition doesn't have its own request_queue
or queue_limits. One way in which this could cause problems is that
the disk could support discard requests and have discard_zeroes_data
set to true, which specifies that data read back following a discard
is guaranteed to be zeros. That will not be true for an encrypted
partition, so any filesystem that issues zeroouts (which the block
layer may implement with discard) would potentially be broken. We
can handle this correctly in a dm target since each dm device has
its own request_queue and we can disable discard_zeroes_data, just
as dm-crypt does for example.
3.) Since the block layer remaps bios from partitions to the devices
containing them, we'd still need to have ->bi_crypt_key and
initialize it somewhere, e.g. in generic_make_request_checks()
before it does the partition remapping. We can't simply read
->bi_bdev->bd_default_key from the PFK module.
4.) With a block device ioctl, we'd need to carefully handle the cases
where the ioctl is executed while someone else has the block device
open (fail with EBUSY?) or while the block device's mapping already
has pages cached (sync and invalidate them?). This would not be too
difficult, but with a dm target neither of these is a problem.
Change-Id: Ia3884842004cfb84d315ef38e54ab4f35b48cf5f
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
Enable wrapped key support for FBE where the keys are
wrapped and unwrapped in a secure environment before
using them.
Change-Id: I4f9a4a08d0b4795f81c7d1dfec43764e521dac77
Signed-off-by: Shivaprasad Hongal <shongal@codeaurora.org>
This reverts 'commit 24c18127e9ba ("sched: Remove sched_ktime_clock()")'
WALT accounting uses ktime_get() as time source to keep windows in
align with the tick. ktime_get() API should not be called while the
timekeeping subsystem is suspended during the system suspend. The
code before the reverted patch has a wrapper around ktime_get() to
avoid calling ktime_get() when timekeeping subsystem is suspended.
The reverted patch removed this wrapper with the assumption that there
will not be any scheduler activity while timekeeping subsystem is
suspended. The timekeeping subsystem is resumed very early even before
non-boot CPUs are brought online. However it is possible that tasks
can wake up from the idle notifiers which gets called before timekeeping
subsystem is resumed.
When this happens, the time read from ktime_get() will not be consistent.
We see a jump from the values that would be returned later when timekeeping
subsystem is resumed. The rq->window_start update happens with incorrect
time. This rq->window_start becomes inconsistent with the rest of the
CPUs's rq->window_start and wallclock time after timekeeping subsystem is
resumed. This results in WALT accounting bugs.
Change-Id: I9c3b2fb9ffbf1103d1bd78778882450560dac09f
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[clingutla@codeaurora.org: Resolved trivial merge conflicts.]
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
New overlay files added for sm6150 does not include
camera headers and results in compilation issue. fix it.
Change-Id: I3874f18fa7d37ab36390cde2f09b6fa53062cfc7
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Fix the core numbering for cluster1 in sdmmagpie.
Without this change topology parsing fails while
parsing cluster1 cores.
Change-Id: Iff41eed6f5826b3c0439eba09bfa03891f0370da
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
Add DT node to support the ARM DynamIQ Shared Unit (DSU) PMU.
This allows the perf subsystem clients to record the events
corresponding to the events related to L3 cache, snoop control
protocol, using its 32-bit counters.
Change-Id: If115f76a275ca1a5aab82b197d7e5baa644ea659
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
Adding llcc perfmon configuration. Perfmon driver can monitor llcc
hardware events, which can be used for profiling.
Change-Id: I28c44081dba058515e57a3fcce5fa63adc3c0617
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
sdmmagpie supports two instance of Last level cache controller
with 256KB system cache. Add dump size to allocate buffers
for llcc cache dumps.
Change-Id: I205d9b5e024845c23e2d1a1e296817ffca963252
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
The EUD (Embedded USB Debugger) is a mini-USB hub implemented
on chip to support the USB-based debug and trace capabilities.
Add device tree node to support EUD on sdmmagpie based platforms.
Change-Id: I6573b4064410ba9d0669976eaa8012116ce3ab04
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
Add ODL(On Device Logging) mode that it can read messages
from the mhi bus channel to user space via a device node
in qdss bridge driver.
Change-Id: I9d8f420ba8047adb4f27a284c6388faf899eada2
Signed-off-by: Shaoqing Liu <shaoqingliu@codeaurora.org>
