nhu/kernel_a52xq
Watch
1
Fork
You've already forked kernel_a52xq
 0
mirror of https://github.com/a52xq-dev/kernel.git synced 2026-10-18 21:58:11 +07:00
Code Issues Projects Releases Wiki Activity

treewide: import latest Galaxy A52 5G kernel

Browse source 
* this imports the latest version of SM-A526B kernel from https://opensource.samsung.com/uploadSearch?searchValue=SM-A526B
This commit is contained in:
itsaschoolbus 2026-03-16 19:10:56 +07:00
commit 34794f4cb2
Signed by: nhu
GPG key ID: 748DE2C9D86C11CB
9305 changed files with 5955533 additions and 20812 deletions
Download patch file Download diff file Expand all files Collapse all files

45
Android.bp Normal file
View file

@ -0,0 +1,45 @@
cc_binary_host {
name: "unifdef",
srcs: ["scripts/unifdef.c"],
sanitize: {
never: true,
},
}
genrule {
name: "gen-headers_install.sh",
srcs: ["scripts/headers_install.sh"],
tools: ["unifdef"],
out: ["headers_install.sh"],
cmd: "sed 's+scripts/unifdef+$(location unifdef)+g' $(in) > $(out)",
}
cc_prebuilt_binary {
name: "headers_install.sh",
device_supported: false,
host_supported: true,
srcs: [":gen-headers_install.sh"],
}
// Use the following for verbose output from kernel_headers.py.
// kernel_headers_verbose = "--verbose "
// Use the following for minimal output from kernel_headers.py.
kernel_headers_verbose = ""
build = ["gen_headers_arm.bp", "gen_headers_arm64.bp"]
cc_library_headers {
name: "qti_kernel_headers",
arch: {
arm: {
generated_headers: ["qti_generate_kernel_headers_arm"],
export_generated_headers: ["qti_generate_kernel_headers_arm"],
},
arm64: {
generated_headers: ["qti_generate_kernel_headers_arm64"],
export_generated_headers: ["qti_generate_kernel_headers_arm64"],
},
},
vendor_available: true,
recovery_available: true,
}

226
AndroidKernel.mk Normal file
View file

@ -0,0 +1,226 @@
#Android makefile to build kernel as a part of Android Build
PERL = perl
KERNEL_TARGET := $(strip $(INSTALLED_KERNEL_TARGET))
ifeq ($(KERNEL_TARGET),)
INSTALLED_KERNEL_TARGET := $(PRODUCT_OUT)/kernel
endif
ifneq ($(TARGET_KERNEL_APPEND_DTB), true)
$(info Using DTB Image)
INSTALLED_DTBIMAGE_TARGET := $(PRODUCT_OUT)/dtb.img
endif
TARGET_KERNEL_MAKE_ENV := $(strip $(TARGET_KERNEL_MAKE_ENV))
ifeq ($(TARGET_KERNEL_MAKE_ENV),)
KERNEL_MAKE_ENV :=
else
KERNEL_MAKE_ENV := $(TARGET_KERNEL_MAKE_ENV)
endif
TARGET_KERNEL_ARCH := $(strip $(TARGET_KERNEL_ARCH))
ifeq ($(TARGET_KERNEL_ARCH),)
KERNEL_ARCH := arm
else
KERNEL_ARCH := $(TARGET_KERNEL_ARCH)
endif
TARGET_KERNEL_HEADER_ARCH := $(strip $(TARGET_KERNEL_HEADER_ARCH))
ifeq ($(TARGET_KERNEL_HEADER_ARCH),)
KERNEL_HEADER_ARCH := $(KERNEL_ARCH)
else
$(warning Forcing kernel header generation only for '$(TARGET_KERNEL_HEADER_ARCH)')
KERNEL_HEADER_ARCH := $(TARGET_KERNEL_HEADER_ARCH)
endif
KERNEL_HEADER_DEFCONFIG := $(strip $(KERNEL_HEADER_DEFCONFIG))
ifeq ($(KERNEL_HEADER_DEFCONFIG),)
KERNEL_HEADER_DEFCONFIG := $(KERNEL_DEFCONFIG)
endif
# Force 32-bit binder IPC for 64bit kernel with 32bit userspace
ifeq ($(KERNEL_ARCH),arm64)
ifeq ($(TARGET_ARCH),arm)
KERNEL_CONFIG_OVERRIDE := CONFIG_ANDROID_BINDER_IPC_32BIT=y
endif
endif
TARGET_KERNEL_CROSS_COMPILE_PREFIX := $(strip $(TARGET_KERNEL_CROSS_COMPILE_PREFIX))
ifeq ($(TARGET_KERNEL_CROSS_COMPILE_PREFIX),)
KERNEL_CROSS_COMPILE := arm-eabi-
else
KERNEL_CROSS_COMPILE := $(shell pwd)/$(TARGET_TOOLS_PREFIX)
endif
ifeq ($(KERNEL_LLVM_SUPPORT), true)
ifeq ($(KERNEL_SD_LLVM_SUPPORT), true) #Using sd-llvm compiler
ifeq ($(shell echo $(SDCLANG_PATH) | head -c 1),/)
KERNEL_LLVM_BIN := $(SDCLANG_PATH)/clang
else
KERNEL_LLVM_BIN := $(shell pwd)/$(SDCLANG_PATH)/clang
endif
$(warning "Using sdllvm" $(KERNEL_LLVM_BIN))
else
KERNEL_LLVM_BIN := $(shell pwd)/$(CLANG) #Using aosp-llvm compiler
$(warning "Using aosp-llvm" $(KERNEL_LLVM_BIN))
endif
endif
ifeq ($(TARGET_PREBUILT_KERNEL),)
KERNEL_GCC_NOANDROID_CHK := $(shell (echo "int main() {return 0;}" | $(KERNEL_CROSS_COMPILE)gcc -E -mno-android - > /dev/null 2>&1 ; echo $$?))
real_cc :=
ifeq ($(KERNEL_LLVM_SUPPORT),true)
real_cc := REAL_CC=$(KERNEL_LLVM_BIN) CLANG_TRIPLE=aarch64-linux-gnu-
else
ifeq ($(strip $(KERNEL_GCC_NOANDROID_CHK)),0)
KERNEL_CFLAGS := KCFLAGS=-mno-android
endif
endif
mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
current_dir := $(notdir $(patsubst %/,%,$(dir $(mkfile_path))))
TARGET_KERNEL := msm-$(TARGET_KERNEL_VERSION)
ifeq ($(TARGET_KERNEL),$(current_dir))
# New style, kernel/msm-version
BUILD_ROOT_LOC := ../../
TARGET_KERNEL_SOURCE := kernel/$(TARGET_KERNEL)
KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/kernel/$(TARGET_KERNEL)
KERNEL_SYMLINK := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
KERNEL_USR := $(KERNEL_SYMLINK)/usr
else
# Legacy style, kernel source directly under kernel
KERNEL_LEGACY_DIR := true
BUILD_ROOT_LOC := ../
TARGET_KERNEL_SOURCE := kernel
KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
endif
KERNEL_CONFIG := $(KERNEL_OUT)/.config
ifeq ($(KERNEL_DEFCONFIG)$(wildcard $(KERNEL_CONFIG)),)
$(error Kernel configuration not defined, cannot build kernel)
else
TARGET_USES_UNCOMPRESSED_KERNEL := $(shell grep "CONFIG_BUILD_ARM64_UNCOMPRESSED_KERNEL=y" $(TARGET_KERNEL_SOURCE)/arch/arm64/configs/$(KERNEL_DEFCONFIG))
ifeq ($(TARGET_USES_UNCOMPRESSED_KERNEL),)
ifeq ($(KERNEL_ARCH),arm64)
TARGET_PREBUILT_INT_KERNEL := $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/Image.gz
else
TARGET_PREBUILT_INT_KERNEL := $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/zImage
endif
else
$(info Using uncompressed kernel)
TARGET_PREBUILT_INT_KERNEL := $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/Image
endif
ifeq ($(TARGET_KERNEL_APPEND_DTB), true)
$(info Using appended DTB)
TARGET_PREBUILT_INT_KERNEL := $(TARGET_PREBUILT_INT_KERNEL)-dtb
endif
KERNEL_HEADERS_INSTALL := $(KERNEL_OUT)/usr
KERNEL_MODULES_INSTALL ?= system
KERNEL_MODULES_OUT ?= $(PRODUCT_OUT)/$(KERNEL_MODULES_INSTALL)/lib/modules
TARGET_PREBUILT_KERNEL := $(TARGET_PREBUILT_INT_KERNEL)
BOARD_VENDOR_KERNEL_MODULES += $(wildcard $(KERNEL_MODULES_OUT)/*.ko)
define mv-modules
mdpath=`find $(KERNEL_MODULES_OUT) -type f -name modules.dep`;\
if [ "$$mdpath" != "" ];then\
mpath=`dirname $$mdpath`;\
ko=`find $$mpath/kernel -type f -name *.ko`;\
for i in $$ko; do mv $$i $(KERNEL_MODULES_OUT)/; done;\
fi
endef
define clean-module-folder
mdpath=`find $(KERNEL_MODULES_OUT) -type f -name modules.dep`;\
if [ "$$mdpath" != "" ];then\
mpath=`dirname $$mdpath`; rm -rf $$mpath;\
fi
endef
ifneq ($(KERNEL_LEGACY_DIR),true)
$(KERNEL_USR): $(KERNEL_HEADERS_INSTALL)
rm -rf $(KERNEL_SYMLINK)
ln -s kernel/$(TARGET_KERNEL) $(KERNEL_SYMLINK)
$(TARGET_PREBUILT_INT_KERNEL): $(KERNEL_USR)
endif
$(KERNEL_OUT):
mkdir -p $(KERNEL_OUT)
$(KERNEL_CONFIG): $(KERNEL_OUT)
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_DEFCONFIG)
$(hide) if [ ! -z "$(KERNEL_CONFIG_OVERRIDE)" ]; then \
echo "Overriding kernel config with '$(KERNEL_CONFIG_OVERRIDE)'"; \
echo $(KERNEL_CONFIG_OVERRIDE) >> $(KERNEL_OUT)/.config; \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) oldconfig; fi
ifeq ($(TARGET_KERNEL_APPEND_DTB), true)
TARGET_PREBUILT_INT_KERNEL_IMAGE := $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/Image
$(TARGET_PREBUILT_INT_KERNEL_IMAGE): $(KERNEL_USR)
$(TARGET_PREBUILT_INT_KERNEL_IMAGE): $(KERNEL_OUT) $(KERNEL_HEADERS_INSTALL)
$(hide) echo "Building kernel modules..."
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_CFLAGS) Image
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_CFLAGS) modules
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) INSTALL_MOD_PATH=$(BUILD_ROOT_LOC)../$(KERNEL_MODULES_INSTALL) INSTALL_MOD_STRIP=1 $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) modules_install
$(mv-modules)
$(clean-module-folder)
$(TARGET_PREBUILT_INT_KERNEL): $(TARGET_PREBUILT_INT_KERNEL_IMAGE)
$(hide) echo "Building kernel..."
$(hide) rm -rf $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/dts
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_CFLAGS)
else
TARGET_PREBUILT_INT_KERNEL_IMAGE := $(TARGET_PREBUILT_INT_KERNEL)
$(TARGET_PREBUILT_INT_KERNEL): $(KERNEL_OUT) $(KERNEL_HEADERS_INSTALL)
$(hide) echo "Building kernel..."
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_CFLAGS)
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_CFLAGS) modules
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) INSTALL_MOD_PATH=$(BUILD_ROOT_LOC)../$(KERNEL_MODULES_INSTALL) INSTALL_MOD_STRIP=1 $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) modules_install
$(mv-modules)
$(clean-module-folder)
endif
$(KERNEL_HEADERS_INSTALL): $(KERNEL_OUT)
$(hide) if [ ! -z "$(KERNEL_HEADER_DEFCONFIG)" ]; then \
rm -f $(BUILD_ROOT_LOC)$(KERNEL_CONFIG); \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_HEADER_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_HEADER_DEFCONFIG); \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_HEADER_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) headers_install;\
if [ -d "$(KERNEL_HEADERS_INSTALL)/include/bringup_headers" ]; then \
cp -Rf $(KERNEL_HEADERS_INSTALL)/include/bringup_headers/* $(KERNEL_HEADERS_INSTALL)/include/ ;\
fi ;\
fi
$(hide) if [ "$(KERNEL_HEADER_DEFCONFIG)" != "$(KERNEL_DEFCONFIG)" ]; then \
echo "Used a different defconfig for header generation"; \
rm -f $(BUILD_ROOT_LOC)$(KERNEL_CONFIG); \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) $(KERNEL_DEFCONFIG); fi
$(hide) if [ ! -z "$(KERNEL_CONFIG_OVERRIDE)" ]; then \
echo "Overriding kernel config with '$(KERNEL_CONFIG_OVERRIDE)'"; \
echo $(KERNEL_CONFIG_OVERRIDE) >> $(KERNEL_OUT)/.config; \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) oldconfig; fi
# Creating a dtb.img once the kernel is compiled if TARGET_KERNEL_APPEND_DTB is set to be false
$(INSTALLED_DTBIMAGE_TARGET): $(TARGET_PREBUILT_INT_KERNEL)
cat $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/dts/vendor/qcom/*.dtb > $@
.PHONY: kerneltags
kerneltags: $(KERNEL_OUT) $(KERNEL_CONFIG)
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) tags
.PHONY: kernelconfig
kernelconfig: $(KERNEL_OUT) $(KERNEL_CONFIG)
env KCONFIG_NOTIMESTAMP=true \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) menuconfig
env KCONFIG_NOTIMESTAMP=true \
$(MAKE) -C $(TARGET_KERNEL_SOURCE) O=$(BUILD_ROOT_LOC)$(KERNEL_OUT) $(KERNEL_MAKE_ENV) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(KERNEL_CROSS_COMPILE) $(real_cc) savedefconfig
cp $(KERNEL_OUT)/defconfig $(TARGET_KERNEL_SOURCE)/arch/$(KERNEL_ARCH)/configs/$(KERNEL_DEFCONFIG)
endif
endif

10
Documentation/ABI/testing/sysfs-block-zram
View file

@ -137,3 +137,13 @@ Description:
The writeback_limit file is read-write and specifies the maximum
amount of writeback ZRAM can do. The limit could be changed
in run time.
What: /sys/block/zram<id>/use_dedup
Date: March 2017
Contact: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Description:
The use_dedup file is read-write and specifies deduplication
feature is used or not. If enabled, duplicated data is
managed by reference count and will not be stored in memory
twice. Benefit of this feature largely depends on the workload
so keep attention when use.

146
Documentation/ABI/testing/sysfs-bus-i3c Normal file
View file

@ -0,0 +1,146 @@
What: /sys/bus/i3c/devices/i3c-<bus-id>
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
An I3C bus. This directory will contain one sub-directory per
I3C device present on the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/current_master
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
Expose the master that owns the bus (<bus-id>-<master-pid>) at
the time this file is read. Note that bus ownership can change
overtime, so there's no guarantee that when the read() call
returns, the value returned is still valid.
What: /sys/bus/i3c/devices/i3c-<bus-id>/mode
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See
the I3C specification for a detailed description of what each
of these modes implies.
What: /sys/bus/i3c/devices/i3c-<bus-id>/i3c_scl_frequency
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
The frequency (expressed in Hz) of the SCL signal when
operating in I3C SDR mode.
What: /sys/bus/i3c/devices/i3c-<bus-id>/i2c_scl_frequency
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
The frequency (expressed in Hz) of the SCL signal when
operating in I2C mode.
What: /sys/bus/i3c/devices/i3c-<bus-id>/dynamic_address
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
Dynamic address assigned to the master controller. This
address may change if the bus is re-initialized.
What: /sys/bus/i3c/devices/i3c-<bus-id>/bcr
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
BCR stands for Bus Characteristics Register and express the
device capabilities in term of speed, maximum read/write
length, etc. See the I3C specification for more details.
This entry describes the BCR of the master controller driving
the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/dcr
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
DCR stands for Device Characteristics Register and express the
device capabilities in term of exposed features. See the I3C
specification for more details.
This entry describes the DCR of the master controller driving
the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/pid
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
See the I3C specification for more details.
This entry describes the PID of the master controller driving
the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/hdrcap
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
Expose the HDR (High Data Rate) capabilities of a device.
Returns a list of supported HDR mode, each element is separated
by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl".
See the I3C specification for more details about these HDR
modes.
This entry describes the HDRCAP of the master controller
driving the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
An I3C device present on I3C bus identified by <bus-id>. Note
that all devices are represented including the master driving
the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/dynamic_address
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
Dynamic address assigned to device <bus-id>-<device-pid>. This
address may change if the bus is re-initialized.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/bcr
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
BCR stands for Bus Characteristics Register and express the
device capabilities in term of speed, maximum read/write
length, etc. See the I3C specification for more details.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/dcr
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
DCR stands for Device Characteristics Register and express the
device capabilities in term of exposed features. See the I3C
specification for more details.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
See the I3C specification for more details.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/hdrcap
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
Expose the HDR (High Data Rate) capabilities of a device.
Returns a list of supported HDR mode, each element is separated
by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl".
See the I3C specification for more details about these HDR
modes.
What: /sys/bus/i3c/devices/<bus-id>-<device-pid>
KernelVersion: 4.20
Contact: linux-i3c@vger.kernel.org
Description:
These directories are just symbolic links to
/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>.

7
Documentation/DMA-attributes.txt
View file

@ -156,3 +156,10 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
DMA_ATTR_IOMMU_USE_LLC_NWA
------------------------------------
DMA_ATTR_IOMMU_USE_LLC_NWA: Overrides the bus attributes to use
System Cache(LLC) with allocation policy as Inner Non-Cacheable, Outer Cacheable:
Write-Back, Read-Allocate, No Write-Allocate policy.

16
Documentation/admin-guide/kernel-parameters.txt
View file

@ -436,6 +436,10 @@
embedded devices based on command line input.
See Documentation/block/cmdline-partition.txt
boot_cpus= [SMP]
Rather than attempting to online all possible CPUs at
boot time, only online the specified set of CPUs.
boot_delay= Milliseconds to delay each printk during boot.
Values larger than 10 seconds (10000) are changed to
no delay (0).
@ -479,16 +483,21 @@
ccw_timeout_log [S390]
See Documentation/s390/CommonIO for details.
cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
cgroup_disable= [KNL] Disable a particular controller or optional feature
Format: {name of the controller(s) or feature(s) to disable}
The effects of cgroup_disable=foo are:
- foo isn't auto-mounted if you mount all cgroups in
a single hierarchy
- foo isn't visible as an individually mountable
subsystem
- if foo is an optional feature then the feature is
disabled and corresponding cgroup files are not
created
{Currently only "memory" controller deal with this and
cut the overhead, others just disable the usage. So
only cgroup_disable=memory is actually worthy}
Specifying "pressure" disables per-cgroup pressure
stall information accounting feature
cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1
Format: { { controller | "all" | "named" }
@ -888,6 +897,9 @@
dis_ucode_ldr [X86] Disable the microcode loader.
dm= [DM] Allows early creation of a device-mapper device.
See Documentation/device-mapper/boot.txt.
dma_debug=off If the kernel is compiled with DMA_API_DEBUG support,
this option disables the debugging code at boot.

23
Documentation/arm/msm/boot.txt Normal file
View file

@ -0,0 +1,23 @@
Introduction
=============
The power management integrated circuit (PMIC) records the reason the
Application processor was powered on in Shared Memory.
The hardware and software used is the shared memory interface. This document
is not for the purpose of describing this interface, but to identify the
possible values for this data item.
Description
===========
Shared memory item (SMEM_POWER_ON_STATUS_INFO) is read to get access to
this data. The table below identifies the possible values stored.
power_on_status values set by the PMIC for power on event:
----------------------------------------------------------
0x01 -- keyboard power on
0x02 -- RTC alarm
0x04 -- cable power on
0x08 -- SMPL
0x10 -- Watch Dog timeout
0x20 -- USB charger
0x40 -- Wall charger
0xFF -- error reading power_on_status value

196
Documentation/arm/msm/glink_pkt.txt Normal file
View file

@ -0,0 +1,196 @@
Introduction
============
Glink packet drivers are companion adaptation driver which use the kernel APIs
to expose the Glink core logical channels as charecter devices to the
user-space clients.
The Glink core APIs are detailed in Documentation/arm/msm/glink.txt.
Software description
====================
Glink packet drivers supports the Glink core APIs to user-space client through
standard file operations like open, read, write, ioctl, poll and release etc.
The standard Linux permissions are used for the device node and SELinux does
further security checks.
Device node [0..n]
|
|
-------------------
| VFS Framework |
-------------------
| |
| |
------- -------
| CDEV | | CDEV |
| Dev 0 |...| Dev n |
----------------------
| Glink packet driver |
----------------------
|
|
-----------------
| |
| G-Link core |
| |
-----------------
|
|
To Remote System
The file operations map to the G-link client API as follows:
Open():
----------
The Open system call is mapped to glink_open() which opens a channel. The
expected channel configuration has to done through DT files. The full DT schema
is detailed in Documentation/devicetree/bindings/arm/msm/glinkpkt.txt.
Open on the glink packet character device is a blocking call which blocks until
the channel is fully open by both local processor and remote processor.
Clients can configure the blocking time through a device configurable parameter
defined per device.
The timeout value is specified in seconds with a default timeout of 1 second.
A negative value indicates an infinite wait.
Example:
# get open timeout value
cat /sys/class/glinkpkt/device_name/open_timeout
# set to 20 seconds value
echo 20 > /sys/class/glinkpkt/device_name/open_timeout
If the channel is not opened by remote processor or any other problem which
fails the channel to be ready will result in timeout and -ETIMEOUT will return
to client. Open on success returns the valid file descriptor to client and on
fail case standard Linux error codes.
The same device can be opened by multiple clients but passing the same file
descriptor from multiple threads may lead unexpected results.
Write():
----------
The Write system call is mapped to glink_tx() which transmits the data over the
glink channel.
Read():
----------
The Read system call consumes any pending data on the channel. Glink signals
incoming data through the glink_notify_rx() call back and the glink packet
driver queues the data internally and provides to client through read system
call. Once the Read is completed, the glink packet driver calls glink_rx_done()
API to notify the completion of receiving operation to Glink core.
+
User-Space | Kernel-Space
|
|
+---------+ | +----------+ +------------+
| Local | | | GlinkPKT | | |
| Client | | | Driver | | Glink core |
| | | | | | |
+---------+ | +----------+ +------------+
|
+ | + +
| | | |
| open() | glink_pkt_open() | glink_open() |
| +--------------> | +-----------------> | +-----------------> |
| | | |
| File Handle[fd]| Valid Fd | Handle |
| <--------------+ | <-----------------+ | <-----------------+ |
| | | |
| Ioctl() | | |
| QUEUE_RX_INTENT | glink_pkt_ioctl() | glink_queue_rx_intent()
| +--------------> | +-----------------> | +-----------------> |
| | | |
| | | |
| <----------------------------------------------------------+ |
| | | |
| Read() | glink_pkt_read() | |
| +--------------> | +-----------------> | +---+ |
| | | | |
| | Wait for data |
| | | <---+ |
| | | glink_notify_rx() |
| | | <-----------------+ |
| | Wake-up read() | |
| | copy_to_user() | |
| read() return | <-----------------+ | |
| <--------------+ | | |
+ | + +
|
|
+
Clients can also poll on device node for POLLIN mask to get notification for
any incoming data. Clients have to call the GLINK_PKT_IOCTL_QUEUE_RX_INTENT
ioctl to queue the RX buffer to glink core in advance.
Release():
----------
The Release system call is mapped to glink_close() to close a channel and free
the resources.
Poll():
----------
The Poll system call provides waiting operation like wait for incoming data on
POLLIN mask and to get the TIOCM signal notification on POLLPRI mask. Clients
can wait on poll for POLLPRI mask to get any notification regarding TICOM
signals. In SSR case Poll call will return with POLLHUP mask and in this case
client has to close and re-open the port.
* POLLPRI - TIOCM bits changed
* POLLIN - RX data available
* POLLHUP - link is down due to either remote side closing or an SSR
Ioctl():
----------
Multiple ioctls are supported to get the TICOM signal status and to queue the
Rx intent with Glink core. Supported ioctls are TIOCMSET, TIOCMGET, TIOCMBIS,
TIOCMBIC and GLINK_PKT_IOCTL_QUEUE_RX_INTENT.
The GLINK_PKT_IOCTL_QUEUE_RX_INTENT ioctl is mapped to glink_queue_rx_intent()
API which queues an RX intent with Glink core.
Signals:
==========
Glink protocol provoide 32-bit control signal field to pass through for the
clients-specific signaling where as Glink packet driver client which are from
user space can use the signal filed as mentioned below.
* 31:28 - Reserved for SMD RS-232 signals
* 27:16 - Pass through for client usage
* 15:0 - TICOM bits
SSR operation:
==============
On remote subsystem restart all open channels on that edge will be closed and
local clients have to close and re-open the channel to re-start the
communication. All blocking calls such as open, read and write will be returned
with -ENETRESET and the poll call will be return with the POLLHUP error codes.
Files:
==========
Documentation/devicetree/bindings/arm/msm/glinkpkt.txt
drivers/soc/qcom/msm_glink_pkt.c
Wakelock:
==========
By default, GLINK PKT will acquire a wakelock for 2 seconds. To optimize this
behavior, use the poll() function:
1. Client calls poll() which blocks until data is available to read
2. Data comes in, GLINK PKT grabs a wakelock and poll()is unblocked
3. Client grabs wakelock to prevent system from suspending
4. Client calls GLINK PKT read() to read the data
5. GLINK PKT releases its wakelock
6. Client Processes the data
7. Client releases the wakelock
Logging:
==========
cat /d/ipc_logging/glink_pkt/log_cont

361
Documentation/arm/msm/msm_ipc_logging.txt Normal file
View file

@ -0,0 +1,361 @@
Introduction
============
This module will be used to log the events by any module/driver which
enables Inter Processor Communication (IPC). Some of the IPC drivers such
as Message Routers, Multiplexers etc. which act as a passive pipe need
some mechanism to log their events. Since all such IPC drivers handle a
large amount of traffic/events, using kernel logs renders kernel logs
unusable by other drivers and also degrades the performance of IPC
drivers. This new module will help in logging such high frequency IPC
driver events while keeping the standard kernel logging mechanism
intact.
Hardware description
====================
This module does not drive any hardware resource and will only use the
kernel memory-space to log the events.
Software description
====================
Design Goals
------------
This module is designed to
* support logging for drivers handling large amount of
traffic/events
* define & differentiate events/logs from different drivers
* support both id-based and stream-based logging
* support extracting the logs from both live target & memory dump
IPC Log Context
----------------
This module will support logging by multiple drivers. To differentiate
between the multiple drivers that are using this logging mechanism, each
driver will be assigned a unique context by this module. Associated with
each context is the logging space, dynamically allocated from the kernel
memory-space, specific to that context so that the events logged using that
context will not interfere with other contexts.
Event Logging
--------------
Every event will be logged as a <Type: Size: Value> combination. Type
field identifies the type of the event that is logged. Size field represents
the size of the log information. Value field represents the actual
information being logged. This approach will support both id-based logging
and stream-based logging. This approach will also support logging sub-events
of an event. This module will provide helper routines to encode/decode the
logs to/from this format.
Encode Context
---------------
Encode context is a temporary storage space that will be used by the client
drivers to log the events in <Type: Size: Value> format. The client drivers
will perform an encode start operation to initialize the encode context
data structure. Then the client drivers will log their events into the
encode context. Upon completion of event logging, the client drivers will
perform an encode end operation to finalize the encode context data
structure to be logged. Then this updated encode context data structure
will be written into the client driver's IPC Log Context. The maximum
event log size will be defined as 256 bytes.
Log Space
----------
Each context (Figure 1) has an associated log space, which is dynamically
allocated from the kernel memory-space. The log space is organized as a list of
1 or more kernel memory pages. Each page (Figure 2) contains header information
which is used to differentiate the log kernel page from the other kernel pages.
0 ---------------------------------
| magic_no = 0x25874452 |
---------------------------------
| nmagic_no = 0x52784425 |
---------------------------------
| version |
---------------------------------
| user_version |
---------------------------------
| log_id |
---------------------------------
| header_size |
---------------------------------
| |
| |
| name [20 chars] |
| |
| |
---------------------------------
| run-time data structures |
---------------------------------
Figure 1 - Log Context Structure
31 0
0 ---------------------------------
| magic_no = 0x52784425 |
---------------------------------
| nmagic_no = 0xAD87BBDA |
---------------------------------
|1| page_num |
---------------------------------
| read_offset | write_offset |
---------------------------------
| log_id |
---------------------------------
| start_time low word |
| start_time high word |
---------------------------------
| end_time low word |
| end_time high word |
---------------------------------
| context offset |
---------------------------------
| run-time data structures |
. . . . .
---------------------------------
| |
| Log Data |
. . .
. . .
| |
--------------------------------- PAGE_SIZE - 1
Figure 2 - Log Page Structure
In addition to extracting logs at runtime through DebugFS, IPC Logging has been
designed to allow extraction of logs from a memory dump. The magic numbers,
timestamps, and context offset are all added to support the memory-dump
extraction use case.
Design
======
Alternate solutions discussed include using kernel & SMEM logs which are
limited in size and hence using them render them unusable by other drivers.
Also kernel logging into serial console is slowing down the performance of
the drivers by multiple times and sometimes lead to APPs watchdog bite.
Power Management
================
Not-Applicable
SMP/multi-core
==============
This module uses spinlocks & mutexes to handle multi-core safety.
Security
========
Not-Applicable
Performance
===========
This logging mechanism, based on experimental data, is not expected to
cause a significant performance degradation. Under worst case, it can
cause 1 - 2 percent degradation in the throughput of the IPC Drivers.
Interface
=========
Exported Data Structures
------------------------
struct encode_context {
struct tsv_header hdr;
char buff[MAX_MSG_SIZE];
int offset;
};
struct decode_context {
int output_format;
char *buff;
int size;
};
Kernel-Space Interface APIs
----------------------------
/*
* ipc_log_context_create: Create a ipc log context
*
* @max_num_pages: Number of pages of logging space required (max. 10)
* @mod_name : Name of the directory entry under DEBUGFS
* @user_version : Version number of user-defined message formats
*
* returns reference to context on success, NULL on failure
*/
void * ipc_log_context_create(int max_num_pages,
const char *mod_name);
/*
* msg_encode_start: Start encoding a log message
*
* @ectxt: Temporary storage to hold the encoded message
* @type: Root event type defined by the module which is logging
*/
void msg_encode_start(struct encode_context *ectxt, uint32_t type);
/*
* msg_encode_end: Complete the message encode process
*
* @ectxt: Temporary storage which holds the encoded message
*/
void msg_encode_end(struct encode_context *ectxt);
/*
* tsv_timestamp_write: Writes the current timestamp count
*
* @ectxt: Context initialized by calling msg_encode_start()
*
* Returns 0 on success, -ve error code on failure
*/
int tsv_timestamp_write(struct encode_context *ectxt);
/*
* tsv_pointer_write: Writes a data pointer
*
* @ectxt: Context initialized by calling msg_encode_start()
* @pointer: Pointer value to write
*
* Returns 0 on success, -ve error code on failure
*/
int tsv_pointer_write(struct encode_context *ectxt, void *pointer);
/*
* tsv_int32_write: Writes a 32-bit integer value
*
* @ectxt: Context initialized by calling msg_encode_start()
* @n: Integer to write
*
* Returns 0 on success, -ve error code on failure
*/
int tsv_int32_write(struct encode_context *ectxt, int32_t n);
/*
* tsv_byte_array_write: Writes a byte array
*
* @ectxt: Context initialized by calling msg_encode_start()
* @data: Location of data
* @data_size: Size of data to be written
*
* Returns 0 on success, -ve error code on failure
*/
int tsv_byte_array_write(struct encode_context *ectxt,
void *data, int data_size);
/*
* ipc_log_write: Write the encoded message into the log space
*
* @ctxt: IPC log context where the message has to be logged into
* @ectxt: Temporary storage containing the encoded message
*/
void ipc_log_write(unsigned long ctxt, struct encode_context *ectxt);
/*
* ipc_log_string: Helper function to log a string
*
* @dlctxt: IPC Log Context created using ipc_log_context_create()
* @fmt: Data specified using format specifiers
*/
int ipc_log_string(unsigned long dlctxt, const char *fmt, ...);
/*
* tsv_timestamp_read: Reads a timestamp
*
* @ectxt: Context retrieved by reading from log space
* @dctxt: Temporary storage to hold the decoded message
* @format: Output format while dumping through DEBUGFS
*/
void tsv_timestamp_read(struct encode_context *ectxt,
struct decode_context *dctxt, const char *format);
/*
* tsv_pointer_read: Reads a data pointer
*
* @ectxt: Context retrieved by reading from log space
* @dctxt: Temporary storage to hold the decoded message
* @format: Output format while dumping through DEBUGFS
*/
void tsv_pointer_read(struct encode_context *ectxt,
struct decode_context *dctxt, const char *format);
/*
* tsv_int32_read: Reads a 32-bit integer value
*
* @ectxt: Context retrieved by reading from log space
* @dctxt: Temporary storage to hold the decoded message
* @format: Output format while dumping through DEBUGFS
*/
void tsv_int32_read(struct encode_context *ectxt,
struct decode_context *dctxt, const char *format);
/*
* tsv_byte_array_read: Reads a byte array/string
*
* @ectxt: Context retrieved by reading from log space
* @dctxt: Temporary storage to hold the decoded message
* @format: Output format while dumping through DEBUGFS
*/
void tsv_byte_array_read(struct encode_context *ectxt,
struct decode_context *dctxt, const char *format);
/*
* add_deserialization_func: Register a deserialization function to
* to unpack the subevents of a main event
*
* @ctxt: IPC log context to which the deserialization function has
* to be registered
* @type: Main/Root event, defined by the module which is logging, to
* which this deserialization function has to be registered.
* @dfune: Deserialization function to be registered
*
* return 0 on success, -ve value on FAILURE
*/
int add_deserialization_func(unsigned long ctxt, int type,
void (*dfunc)(struct encode_context *,
struct decode_context *));
Driver parameters
=================
Not-Applicable
Config options
==============
Not-Applicable
Dependencies
============
This module will partially depend on CONFIG_DEBUGFS, in order to dump the
logs through debugfs. If CONFIG_DEBUGFS is disabled, the above mentioned
helper functions will perform no operation and return appropriate error
code if the return value is non void. Under such circumstances the logs can
only be extracted through the memory dump.
User space utilities
====================
DEBUGFS
Other
=====
Not-Applicable
Known issues
============
None
To do
=====
None

468
Documentation/arm/msm/remote_debug_drv.txt Normal file
View file

@ -0,0 +1,468 @@
Introduction
============
The goal of this debug feature is to provide a reliable, responsive,
accurate and secure debug capability to developers interested in
debugging MSM subsystem processor images without the use of a hardware
debugger.
The Debug Agent along with the Remote Debug Driver implements a shared
memory based transport mechanism that allows for a debugger (ex. GDB)
running on a host PC to communicate with a remote stub running on
peripheral subsystems such as the ADSP, MODEM etc.
The diagram below depicts end to end the components involved to
support remote debugging:
: :
: HOST (PC) : MSM
: ,--------, : ,-------,
: | | : | Debug | ,--------,
: |Debugger|<--:-->| Agent | | Remote |
: | | : | App | +----->| Debug |
: `--------` : |-------| ,--------, | | Stub |
: : | Remote| | |<---+ `--------`
: : | Debug |<-->|--------|
: : | Driver| | |<---+ ,--------,
: : `-------` `--------` | | Remote |
: : LA Shared +----->| Debug |
: : Memory | Stub |
: : `--------`
: : Peripheral Subsystems
: : (ADSP, MODEM, ...)
Debugger: Debugger application running on the host PC that
communicates with the remote stub.
Examples: GDB, LLDB
Debug Agent: Software that runs on the Linux Android platform
that provides connectivity from the MSM to the
host PC. This involves two portions:
1) User mode Debug Agent application that discovers
processes running on the subsystems and creates
TCP/IP sockets for the host to connect to. In addition
to this, it creates an info (or meta) port that
users can connect to discover the various
processes and their corresponding debug ports.
Remote Debug A character based driver that the Debug
Driver: Agent uses to transport the payload received from the
host to the debug stub running on the subsystem
processor over shared memory and vice versa.
Shared Memory: Shared memory from the SMEM pool that is accessible
from the Applications Processor (AP) and the
subsystem processors.
Remote Debug Privileged code that runs in the kernels of the
Stub: subsystem processors that receives debug commands
from the debugger running on the host and
acts on these commands. These commands include reading
and writing to registers and memory belonging to the
subsystem's address space, setting breakpoints,
single stepping etc.
Hardware description
====================
The Remote Debug Driver interfaces with the Remote Debug stubs
running on the subsystem processors and does not drive or
manage any hardware resources.
Software description
====================
The debugger and the remote stubs use Remote Serial Protocol (RSP)
to communicate with each other. This is widely used protocol by both
software and hardware debuggers. RSP is an ASCII based protocol
and used when it is not possible to run GDB server on the target under
debug.
The Debug Agent application along with the Remote Debug Driver
is responsible for establishing a bi-directional connection from
the debugger application running on the host to the remote debug
stub running on a subsystem. The Debug Agent establishes connectivity
to the host PC via TCP/IP sockets.
This feature uses ADB port forwarding to establish connectivity
between the debugger running on the host and the target under debug.
Please note the Debug Agent does not expose HLOS memory to the
remote subsystem processors.
Design
======
Here is the overall flow:
1) When the Debug Agent application starts up, it opens up a shared memory
based transport channel to the various subsystem processor images.
2) The Debug Agent application sends messages across to the remote stubs
to discover the various processes that are running on the subsystem and
creates debug sockets for each of them.
3) Whenever a process running on a subsystem exits, the Debug Agent
is notified by the stub so that the debug port and other resources
can be reclaimed.
4) The Debug Agent uses the services of the Remote Debug Driver to
transport payload from the host debugger to the remote stub and vice versa.
5) Communication between the Remote Debug Driver and the Remote Debug stub
running on the subsystem processor is done over shared memory (see figure).
SMEM services are used to allocate the shared memory that will
be readable and writeable by the AP and the subsystem image under debug.
A separate SMEM allocation takes place for each subsystem processor
involved in remote debugging. The remote stub running on each of the
subsystems allocates a SMEM buffer using a unique identifier so that both
the AP and subsystem get the same physical block of memory. It should be
noted that subsystem images can be restarted at any time.
However, when a subsystem comes back up, its stub uses the same unique
SMEM identifier to allocate the SMEM block. This would not result in a
new allocation rather the same block of memory in the first bootup instance
is provided back to the stub running on the subsystem.
An 8KB chunk of shared memory is allocated and used for communication
per subsystem. For multi-process capable subsystems, 16KB chunk of shared
memory is allocated to allow for simultaneous debugging of more than one
process running on a single subsystem.
The shared memory is used as a circular ring buffer in each direction.
Thus we have a bi-directional shared memory channel between the AP
and a subsystem. We call this SMQ. Each memory channel contains a header,
data and a control mechanism that is used to synchronize read and write
of data between the AP and the remote subsystem.
Overall SMQ memory view:
:
: +------------------------------------------------+
: | SMEM buffer |
: |-----------------------+------------------------|
: |Producer: LA | Producer: Remote |
: |Consumer: Remote | subsystem |
: | subsystem | Consumer: LA |
: | | |
: | Producer| Consumer|
: +-----------------------+------------------------+
: | |
: | |
: | +--------------------------------------+
: | |
: | |
: v v
: +--------------------------------------------------------------+
: | Header | Data | Control |
: +-----------+---+---+---+-----+----+--+--+-----+---+--+--+-----+
: | | b | b | b | | S |n |n | | S |n |n | |
: | Producer | l | l | l | | M |o |o | | M |o |o | |
: | Ver | o | o | o | | Q |d |d | | Q |d |d | |
: |-----------| c | c | c | ... | |e |e | ... | |e |e | ... |
: | | k | k | k | | O | | | | I | | | |
: | Consumer | | | | | u |0 |1 | | n |0 |1 | |
: | Ver | 0 | 1 | 2 | | t | | | | | | | |
: +-----------+---+---+---+-----+----+--+--+-----+---+--+--+-----+
: | |
: + |
: |
: +------------------------+
: |
: v
: +----+----+----+----+
: | SMQ Nodes |
: |----|----|----|----|
: Node # | 0 | 1 | 2 | ...|
: |----|----|----|----|
: Starting Block Index # | 0 | 3 | 8 | ...|
: |----|----|----|----|
: # of blocks | 3 | 5 | 1 | ...|
: +----+----+----+----+
:
Header: Contains version numbers for software compatibility to ensure
that both producers and consumers on the AP and subsystems know how to
read from and write to the queue.
Both the producer and consumer versions are 1.
: +---------+-------------------+
: | Size | Field |
: +---------+-------------------+
: | 1 byte | Producer Version |
: +---------+-------------------+
: | 1 byte | Consumer Version |
: +---------+-------------------+
Data: The data portion contains multiple blocks [0..N] of a fixed size.
The block size SM_BLOCKSIZE is fixed to 128 bytes for header version #1.
Payload sent from the debug agent app is split (if necessary) and placed
in these blocks. The first data block is placed at the next 8 byte aligned
address after the header.
The number of blocks for a given SMEM allocation is derived as follows:
Number of Blocks = ((Total Size - Alignment - Size of Header
- Size of SMQIn - Size of SMQOut)/(SM_BLOCKSIZE))
The producer maintains a private block map of each of these blocks to
determine which of these blocks in the queue is available and which are free.
Control:
The control portion contains a list of nodes [0..N] where N is number
of available data blocks. Each node identifies the data
block indexes that contain a particular debug message to be transferred,
and the number of blocks it took to hold the contents of the message.
Each node has the following structure:
: +---------+-------------------+
: | Size | Field |
: +---------+-------------------+
: | 2 bytes |Staring Block Index|
: +---------+-------------------+
: | 2 bytes |Number of Blocks |
: +---------+-------------------+
The producer and the consumer update different parts of the control channel
(SMQOut / SMQIn) respectively. Each of these control data structures contains
information about the last node that was written / read, and the actual nodes
that were written/read.
SMQOut Structure (R/W by producer, R by consumer):
: +---------+-------------------+
: | Size | Field |
: +---------+-------------------+
: | 4 bytes | Magic Init Number |
: +---------+-------------------+
: | 4 bytes | Reset |
: +---------+-------------------+
: | 4 bytes | Last Sent Index |
: +---------+-------------------+
: | 4 bytes | Index Free Read |
: +---------+-------------------+
SMQIn Structure (R/W by consumer, R by producer):
: +---------+-------------------+
: | Size | Field |
: +---------+-------------------+
: | 4 bytes | Magic Init Number |
: +---------+-------------------+
: | 4 bytes | Reset ACK |
: +---------+-------------------+
: | 4 bytes | Last Read Index |
: +---------+-------------------+
: | 4 bytes | Index Free Write |
: +---------+-------------------+
Magic Init Number:
Both SMQ Out and SMQ In initialize this field with a predefined magic
number so as to make sure that both the consumer and producer blocks
have fully initialized and have valid data in the shared memory control area.
Producer Magic #: 0xFF00FF01
Consumer Magic #: 0xFF00FF02
SMQ Out's Last Sent Index and Index Free Read:
Only a producer can write to these indexes and they are updated whenever
there is new payload to be inserted into the SMQ in order to be sent to a
consumer.
The number of blocks required for the SMQ allocation is determined as:
(payload size + SM_BLOCKSIZE - 1) / SM_BLOCKSIZE
The private block map is searched for a large enough continuous set of blocks
and the user data is copied into the data blocks.
The starting index of the free block(s) is updated in the SMQOut's Last Sent
Index. This update keeps track of which index was last written to and the
producer uses it to determine where the the next allocation could be done.
Every allocation, a producer updates the Index Free Read from its
collaborating consumer's Index Free Write field (if they are unequal).
This index value indicates that the consumer has read all blocks associated
with allocation on the SMQ and that the producer can reuse these blocks for
subsquent allocations since this is a circular queue.
At cold boot and restart, these indexes are initialized to zero and all
blocks are marked as available for allocation.
SMQ In's Last Read Index and Index Free Write:
These indexes are written to only by a consumer and are updated whenever
there is new payload to be read from the SMQ. The Last Read Index keeps
track of which index was last read by the consumer and using this, it
determines where the next read should be done.
After completing a read, Last Read Index is incremented to the
next block index. A consumer updates Index Free Write to the starting
index of an allocation whenever it has completed processing the blocks.
This is an optimization that can be used to prevent an additional copy
of data from the queue into a client's data buffer and the data in the queue
itself can be used.
Once Index Free Write is updated, the collaborating producer (on the next
data allocation) reads the updated Index Free Write value and it then
updates its corresponding SMQ Out's Index Free Read and marks the blocks
associated with that index as available for allocation. At cold boot and
restart, these indexes are initialized to zero.
SMQ Out Reset# and SMQ In Reset ACK #:
Since subsystems can restart at anytime, the data blocks and control channel
can be in an inconsistent state when a producer or consumer comes up.
We use Reset and Reset ACK to manage this. At cold boot, the producer
initializes the Reset# to a known number ex. 1. Every other reset that the
producer undergoes, the Reset#1 is simply incremented by 1. All the producer
indexes are reset.
When the producer notifies the consumer of data availability, the consumer
reads the producers Reset # and copies that into its SMQ In Reset ACK#
field when they differ. When that occurs, the consumer resets its
indexes to 0.
6) Asynchronous notifications between a producer and consumer are
done using the SMP2P service which is interrupt based.
Power Management
================
None
SMP/multi-core
==============
The driver uses completion to wake up the Debug Agent client threads.
Security
========
From the perspective of the subsystem, the AP is untrusted. The remote
stubs consult the secure debug fuses to determine whether or not the
remote debugging will be enabled at the subsystem.
If the hardware debug fuses indicate that debugging is disabled, the
remote stubs will not be functional on the subsystem. Writes to the
queue will only be done if the driver sees that the remote stub has been
initialized on the subsystem.
Therefore even if any untrusted software running on the AP requests
the services of the Remote Debug Driver and inject RSP messages
into the shared memory buffer, these RSP messages will be discarded and
an appropriate error code will be sent up to the invoking application.
Performance
===========
During operation, the Remote Debug Driver copies RSP messages
asynchronously sent from the host debugger to the remote stub and vice
versa. The debug messages are ASCII based and relatively short
(<25 bytes) and may once in a while go up to a maximum 700 bytes
depending on the command the user requested. Thus we do not
anticipate any major performance impact. Moreover, in a typical
functional debug scenario performance should not be a concern.
Interface
=========
The Remote Debug Driver is a character based device that manages
a piece of shared memory that is used as a bi-directional
single producer/consumer circular queue using a next fit allocator.
Every subsystem, has its own shared memory buffer that is managed
like a separate device.
The driver distinguishes each subsystem processor's buffer by
registering a node with a different minor number.
For each subsystem that is supported, the driver exposes a user space
interface through the following node:
- /dev/rdbg-<subsystem>
Ex. /dev/rdbg-adsp (for the ADSP subsystem)
The standard open(), close(), read() and write() API set is
implemented.
The open() syscall will fail if a subsystem is not present or supported
by the driver or a shared memory buffer cannot be allocated for the
AP - subsystem communication. It will also fail if the subsytem has
not initialized the queue on its side. Here are the error codes returned
in case a call to open() fails:
ENODEV - memory was not yet allocated for the device
EEXIST - device is already opened
ENOMEM - SMEM allocation failed
ECOMM - Subsytem queue is not yet setup
ENOMEM - Failure to initialize SMQ
read() is a blocking call that will return with the number of bytes written
by the subsystem whenever the subsystem sends it some payload. Here are the
error codes returned in case a call to read() fails:
EINVAL - Invalid input
ENODEV - Device has not been opened yet
ERESTARTSYS - call to wait_for_completion_interruptible is interrupted
ENODATA - call to smq_receive failed
write() attempts to send user mode payload out to the subsystem. It can fail
if the SMQ is full. The number of bytes written is returned back to the user.
Here are the error codes returned in case a call to write() fails:
EINVAL - Invalid input
ECOMM - SMQ send failed
In the close() syscall, the control information state of the SMQ is
initialized to zero thereby preventing any further communication between
the AP and the subsystem. Here is the error code returned in case
a call to close() fails:
ENODEV - device wasn't opened/initialized
The Remote Debug driver uses SMP2P for bi-directional AP to subsystem
notification. Notifications are sent to indicate that there are new
debug messages available for processing. Each subsystem that is
supported will need to add a device tree entry per the usage
specification of SMP2P driver.
In case the remote stub becomes non operational or the security configuration
on the subsystem does not permit debugging, any messages put in the SMQ will
not be responded to. It is the responsibility of the Debug Agent app and the
host debugger application such as GDB to timeout and notify the user of the
non availability of remote debugging.
Driver parameters
=================
None
Config options
==============
The driver is configured with a device tree entry to map an SMP2P entry
to the device. The SMP2P entry name used is "rdbg". Please see
kernel\Documentation\arm\msm\msm_smp2p.txt for information about the
device tree entry required to configure SMP2P.
The driver uses the SMEM allocation type SMEM_LC_DEBUGGER to allocate memory
for the queue that is used to share data with the subsystems.
Dependencies
============
The Debug Agent driver requires services of SMEM to
allocate shared memory buffers.
SMP2P is used as a bi-directional notification
mechanism between the AP and a subsystem processor.
User space utilities
====================
This driver is meant to be used in conjunction with the user mode
Remote Debug Agent application.
Other
=====
None
Known issues
============
For targets with an external subsystem, we cannot use
shared memory for communication and would have to use the prevailing
transport mechanisms that exists between the AP and the external subsystem.
This driver cannot be leveraged for such targets.
To do
=====
None

1
Documentation/arm64/silicon-errata.txt
View file

@ -59,6 +59,7 @@ stable kernels.
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
| ARM | Cortex-A77 | #1542418 | ARM64_ERRATUM_1542418 |
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
| ARM | MMU-500 | #841119,#826419 | N/A |
| | | | |

4
Documentation/blockdev/zram.txt
View file

@ -173,7 +173,7 @@ compact WO trigger memory compaction
debug_stat RO this file is used for zram debugging purposes
backing_dev RW set up backend storage for zram to write out
idle WO mark allocated slot as idle
use_dedup RW show and set deduplication feature
User space is advised to use the following files to read the device statistics.
@ -223,6 +223,8 @@ line of text and contains the following stats separated by whitespace:
No memory is allocated for such pages.
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
dup_data_size deduplicated data size
meta_data_size the amount of metadata allocated for deduplication feature
File /sys/block/zram<id>/bd_stat

228
Documentation/crypto/msm/qce.txt Normal file
View file

@ -0,0 +1,228 @@
Introduction:
=============
The QTI crypto engine (qce) driver is a module that
provides common services for accessing the QTI crypto device.
Currently, the two main clients of qce are
-qcrypto driver (module provided for accessing CE HW by kernel space apps)
-qcedev driver (module provided for accessing CE HW by user space apps)
The crypto engine (qce) driver is a client to the DMA driver for the QTI
DMA device - Application Data Mover (ADM). ADM is used to provide the DMA
transfer capability between QTI crypto device hardware and DDR memory
for crypto operations.
Figure 1.
---------
Linux kernel
(ex:IPSec)<-----* QTI crypto driver----+
(qcrypto) |
(for kernel space app) |
|
+-->|
|
| *qce <----> QTI
| driver ADM driver <---> ADM HW
+-->| | |
| | |
| | |
| | |
Linux kernel | | |
misc device <--- *QCEDEV Driver-------+ | |
interface (qcedev) (Reg interface) (DMA interface)
(for user space app) \ /
\ /
\ /
\ /
\ /
\ /
\ /
QTI crypto CE3 HW
The entities marked with (*) in the Figure 1, are the software components of
the Linux QTI crypto modules.
===============
IMPORTANT NOTE:
===============
(1) The CE hardware can be accessed either from user space OR kernel space,
at one time. Both user space and kernel space clients cannot access the
qce driver (and the CE hardware) at the same time.
- If your device has user space apps that needs to access the crypto
hardware, make sure to have the qcrypto module disabled/unloaded.
This will result in the kernel space apps to use the registered
software implementation of the crypto algorithms.
- If your device has kernel space apps that needs to access the
crypto hardware, make sure to have qcedev module disabled/unloaded
and implement your user space application to use the software
implementation (ex: openssl/crypto) of the crypto algorithms.
(2) If your device has Playready(Windows Media DRM) application enabled and
uses the qcedev module to access the crypto hardware accelerator,
please be informed that for performance reasons, the CE hardware will need
to be dedicated to playready application. Any other user space application
should be implemented to use the SW implementation (ex: openssl/crypto)
of the crypto algorithms.
Hardware description:
=====================
QTI Crypto HW device family provides a series of algorithms implemented
in the device hardware.
Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
algorithms, and concurrent operations of hashing, and ciphering.
In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides
fast AES algorithms.
In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as
defined by the 3GPP forum.
Software description
====================
The crypto device is defined as a platform device. The driver is
independent of the platform. The driver supports multiple instances of
crypto HW.
All the platform specific parameters are defined in the board init
file, eg. arch/arm/mach-msm/board-msm7x30.c for MSM7x30.
The qce driver provide the common services of HW crypto
access to the two drivers as listed above (qcedev, qcrypto. It sets up
the crypto HW device for the operation, then it requests ADM driver for
the DMA of the crypto operation.
Two ADM channels and two command lists (one command list for each
channel) are involved in an operation.
The setting up of the command lists and the procedure of the operation
of the crypto device are described in the following sections.
The command list for the first DMA channel is set up as follows:
1st command of the list is for the DMA transfer from DDR memory to the
crypto device to input data to crypto device. The dst crci of the command
is set for crci-in for this crypto device.
2nd command is for the DMA transfer is from crypto device to DDR memory for
the authentication result. The src crci is set as crci-hash-done of the
crypto device. If authentication is not required in the operation,
the 2nd command is not used.
The command list for the second DMA channel is set up as follows:
One command to DMA data from crypto device to DDR memory for encryption or
decryption output from crypto device.
To accomplish ciphering and authentication concurrent operations, the driver
performs the following steps:
(a). set up HW crypto device
(b). hit the crypto go register.
(c). issue the DMA command of first channel to the ADM driver,
(d). issue the DMA command of 2nd channel to the ADM driver.
SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish
hash operation (or any authentication only algorithm), 2nd DMA channel is
not required. Only steps (a) to (c) are performed.
At the completion of the DMA operation (for (c) and (d)) ADM driver
invokes the callback registered to the DMA driver. This signifies the end of
the DMA operation(s). The driver reads the status and other information from
the CE hardware register and then invokes the callback to the qce driver client.
This signal the completion and the results of the DMA along with the status of
the CE hardware to the qce driver client. This completes a crypto operation.
In the qce driver initialization, memory for the two command lists, descriptor
lists for each crypto device are allocated out of coherent memory, using Linux
DMA API. The driver pre-configures most of the two ADM command lists
in the initialization. During each crypto operation, minimal set up is required.
src_dscr or/and dst_dscr descriptor list of the ADM command are populated
from the information obtained from the corresponding data structure. eg: for
AEAD request, the following data structure provides the information:
struct aead_request *req
......
req->assoc
req->src
req->dst
The DMA address of a scatter list will be retrieved and set up in the
descriptor list of an ADM command.
Power Management
================
none
Interface:
==========
The interface is defined in qce.h
The clients qcrypto, qcedev drivers are the clients using
the interfaces.
The following services are provided by the qce driver -
qce_open(), qce_close(), qce_ablk_cipher_req(),
qce_hw_support(), qce_process_sha_req()
qce_open() is the first request from the client, ex. QTI crypto
driver (qcedev, qcrypto), to open a crypto engine. It is normally
called at the probe function of the client for a device. During the
probe,
- ADM command list structure will be set up
- Crypto device will be initialized.
- Resource associated with the crypto engine is retrieved by doing
platform_get_resource() or platform_get_resource_byname().
The resources for a device are
- crci-in, crci-out, crci-hash-done
- two DMA channel IDs, one for encryption and decryption input, one for
output.
- base address of the HW crypto device.
qce_close() is the last request from the client. Normally, it is
called from the remove function of the client.
qce_hw_support() allows the client to query what is supported
by the crypto engine hardware.
qce_ablk_cipher_req() provides ciphering service to the client.
qce_process_sha_req() provide hashing service to the client.
qce_aead_req() provide aead service to the client.
Module parameters:
==================
The following module parameters are defined in the board init file.
-CE hardware base register address
-Data mover channel used for transfer to/from CE hardware
These parameters differ in each platform.
Dependencies:
=============
Existing DMA driver.
The transfers are DMA'ed between the crypto hardware and DDR memory via the
data mover, ADM. The data transfers are set up to use the existing dma driver.
User space utilities:
=====================
n/a
Known issues:
=============
n/a
To do:
======
n/a

231
Documentation/crypto/msm/qcedev.txt Normal file
View file

@ -0,0 +1,231 @@
Introduction:
=============
This driver provides IOCTLS for user space application to access crypto
engine hardware for the qcedev crypto services. The driver supports the
following crypto algorithms
- AES-128, AES-256 (ECB, CBC and CTR mode)
- AES-192, (ECB, CBC and CTR mode)
(support exists on platform supporting CE 3.x hardware)
- SHA1/SHA256
- AES-128, AES-256 (XTS), AES CMAC, SHA1/SHA256 HMAC
(support exists on platform supporting CE 4.x hardware)
Hardware description:
=====================
Crypto 3E provides cipher and hash algorithms as defined in the
3GPP forum specifications.
Software description
====================
The driver is a Linux platform device driver. For an msm target,
there can be multiple crypto devices assigned for QCEDEV.
The driver is a misc device driver as well.
The following operations are registered in the driver,
-qcedev_ioctl()
-qcedev_open()
-qcedev_release()
The following IOCTLS are available to the user space application(s)-
Cipher IOCTLs:
--------------
QCEDEV_IOCTL_ENC_REQ is for encrypting data.
QCEDEV_IOCTL_DEC_REQ is for decrypting data.
Hashing/HMAC IOCTLs
-------------------
QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request.
QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac.
QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request.
QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data
packet of known size.
QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC
algorithm) for data packet of known size.
The requests are synchronous. The driver will put the process to
sleep, waiting for the completion of the requests using wait_for_completion().
Since the requests are coming out of user space application, before giving
the requests to the low level qce driver, the ioctl requests and the
associated input/output buffer will have to be safe checked, and copied
to/from kernel space.
The extra copying of requests/buffer can affect the performance. The issue
with copying the data buffer is resolved by having the client use PMEM
allocated buffers.
NOTE: Using memory allocated via PMEM is supported only for in place
operations where source and destination buffers point to the same
location. Support for different source and destination buffers
is not supported currently.
Furthermore, when using PMEM, and in AES CTR mode, when issuing an
encryption or decryption request, a non-zero byteoffset is not
supported.
The design of the driver is to allow multiple open, and multiple requests
to be issued from application(s). Therefore, the driver will internally queue
the requests, and serialize the requests to the low level qce (or qce40) driver.
On an IOCTL request from an application, if there is no outstanding
request, a the driver will issue a "qce" request, otherwise,
the request is queued in the driver queue. The process is suspended
waiting for completion.
On completion of a request by the low level qce driver, the internal
tasklet (done_tasklet) is scheduled. The sole purpose of done_tasklet is
to call the completion of the current active request (complete()), and
issue more requests to the qce, if any.
When the process wakes up from wait_for_completion(), it will collect the
return code, and return the ioctl.
A spin lock is used to protect the critical section of internal queue to
be accessed from multiple tasks, SMP, and completion callback
from qce.
The driver maintains a set of statistics using debug fs. The files are
in /debug/qcedev/stats1, /debug/qcedev/stats2, /debug/qcedev/stats3;
one for each instance of device. Reading the file associated with
a device will retrieve the driver statistics for that device.
Any write to the file will clear the statistics.
Power Management
================
n/a
Interface:
==========
Linux user space applications will need to open a handle
(file descriptor) to the qcedev device. This is achieved by doing
the following to retrieve a file descriptor to the device.
fd = open("/dev/qce", O_RDWR);
..
ioctl(fd, ...);
Once a valid fd is retrieved, user can call the following ioctls with
the fd as the first parameter and a pointer to an appropriate data
structure, qcedev_cipher_op_req or qcedev_sha_op_req (depending on
cipher/hash functionality) as the second parameter.
The following IOCTLS are available to the user space application(s)-
Cipher IOCTLs:
--------------
QCEDEV_IOCTL_ENC_REQ is for encrypting data.
QCEDEV_IOCTL_DEC_REQ is for decrypting data.
The caller of the IOCTL passes a pointer to the structure shown
below, as the second parameter.
struct qcedev_cipher_op_req {
int use_pmem;
union{
struct qcedev_pmem_info pmem;
struct qcedev_vbuf_info vbuf;
};
uint32_t entries;
uint32_t data_len;
uint8_t in_place_op;
uint8_t enckey[QCEDEV_MAX_KEY_SIZE];
uint32_t encklen;
uint8_t iv[QCEDEV_MAX_IV_SIZE];
uint32_t ivlen;
uint32_t byteoffset;
enum qcedev_cipher_alg_enum alg;
enum qcedev_cipher_mode_enum mode;
enum qcedev_oper_enum op;
};
Hashing/HMAC IOCTLs
-------------------
QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request.
QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac.
QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request.
QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data
packet of known size.
QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC
algorithm) for data packet of known size.
The caller of the IOCTL passes a pointer to the structure shown
below, as the second parameter.
struct qcedev_sha_op_req {
struct buf_info data[QCEDEV_MAX_BUFFERS];
uint32_t entries;
uint32_t data_len;
uint8_t digest[QCEDEV_MAX_SHA_DIGEST];
uint32_t diglen;
uint8_t *authkey;
uint32_t authklen;
enum qcedev_sha_alg_enum alg;
struct qcedev_sha_ctxt ctxt;
};
The IOCTLs and associated request data structures are defined in qcedev.h
Module parameters:
==================
The following module parameters are defined in the board init file.
-CE hardware nase register address
-Data mover channel used for transfer to/from CE hardware
These parameters differ in each platform.
Dependencies:
=============
qce driver. Please see Documentation/arm/msm/qce.txt.
User space utilities:
=====================
none
Known issues:
=============
none.
To do:
======
Enhance Cipher functionality:
(1) Add support for handling > 32KB for ciphering functionality when
- operation is not an "in place" operation (source != destination).
(when using PMEM allocated memory)
Limitations:
============
(1) In case of cipher functionality, Driver does not support
a combination of different memory sources for source/destination.
In other words, memory pointed to by src and dst,
must BOTH (src/dst) be "pmem" or BOTH(src/dst) be "vbuf".
(2) In case of hash functionality, driver does not support handling data
buffers allocated via PMEM.
(3) Do not load this driver if your device already has kernel space apps
that need to access the crypto hardware.
Make sure to have qcedev module disabled/unloaded and implement your user
space application to use the software implementation (ex: openssl/crypto)
of the crypto algorithms.
(NOTE: Please refer to details on the limitations listed in qce.txt)
(4) If your device has Playready (Windows Media DRM) application enabled
and uses the qcedev module to access the crypto hardware accelerator,
please be informed that for performance reasons, the CE hardware will
need to be dedicated to playready application. Any other user space
application should be implemented to use the software implementation
(ex: openssl/crypto) of the crypto algorithms.

142
Documentation/crypto/msm/qcrypto.txt Normal file
View file

@ -0,0 +1,142 @@
Introduction:
=============
QTI Crypto (qcrypto) driver is a Linux crypto driver which interfaces
with the Linux kernel crypto API layer to provide the HW crypto functions.
This driver is accessed by kernel space apps via the kernel crypto API layer.
At present there is no means for user space apps to access this module.
Hardware description:
=====================
QTI Crypto HW device family provides a series of algorithms implemented
in the device.
Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
algorithms, and concurrent operations of hashing, and ciphering.
In addition to those functions provided by Crypto 2 HW, Crypto 3 provides fast
AES algorithms.
In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
HMAC-SHA1 hashing algorithm.
In addition to those functions provided by Crypto 3 HW, Crypto 4.0 provides
HMAC-SHA1/SHA256, AES CBC-MAC hashing algorithm and AES XTS/CCM cipher
algorithms.
Software description
====================
The module init function (_qcrypto_init()), does a platform_register(),
to register the driver. As the result, the driver probe function,
_qcrypto_probe(), will be invoked for each registered device.
In the probe function, driver opens the low level CE (qce_open), and
registers the supported algorithms to the kernel crypto API layer.
Currently, qcrypto supports the following algorithms.
ablkcipher -
cbc(aes),ecb(aes),ctr(aes)
ahash -
sha1, sha256
aead -
authenc(hmac(sha1),cbc(aes))
The hmac(sha1), hmac(sha256, authenc(hmac(sha1),cbc(aes)), ccm(aes)
and xts(aes) algorithms are registered for some platforms that
support these in the CE hardware
The HW device can support various algorithms. However, the most important
algorithms to gain the performance using a HW crypto accelerator are
AEAD, and ABLKCIPHER.
AEAD stands for "authentication encryption with association data".
ABLKCIPHER stands of "asynchronous block cipher".
The AEAD structure is described in the following header file aead.h
The design of the driver is to allow multiple requests
issued from kernel client SW (eg IPSec).
Therefore, the driver will have to internally queue the requests, and
serialize the requests to the low level qce driver.
When a request is received from the client, if there is no outstanding
request, a qce (or qce40) request is issued, otherwise, the request is
queued in the driver queue.
On completion of a request, the qce (or qce40) invokes the registered
callback from the qcrypto. The internal tasklet (done_tasklet) is scheduled
in this callback function. The sole purpose of done_tasklet is
to call the completion of the current active request, and
issue more requests to the qce (or qce40), if any exists.
A spin lock is used to protect the critical section of internal queue to
be accessed from multiple tasks, SMP, and completion callback
from qce.
The driver maintains a set of statistics using debug fs. The files are
in /debug/qcrypto/stats1, /debug/qcrypto/stats2, /debug/qcrypto/stats3;
one for each instance of device. Reading the file associated with
a device will retrieve the driver statistics for that device.
Any write to the file will clear the statistics.
Test vectors for authenc(hmac(sha1),cbc(aes)) algorithm are
developed offline, and imported to crypto/testmgr.c, and crypto/testmgr.h.
Power Management
================
none
Interface:
==========
The kernel interface is defined in crypto.h.
Module parameters:
==================
All the platform specific parameters are defined in the board init
file, eg. arch/arm/mach-msm/board-mssm7x30.c for msm7x30.
Dependencies:
=============
qce driver.
User space utilities:
=====================
n/a
Known issues:
=============
n/a
To do:
======
Add Hashing algorithms.
Limitations:
===============
(1) Each packet transfer size (for cipher and hash) is limited to maximum of
32KB. This is a limitation in the crypto engine hardware. Client will
have to break packets larger than 32KB into multiple requests of smaller
size data packets.
(2) Do not load this driver if your device has user space apps that needs to
access the crypto hardware. Please make sure to have the qcrypto module
disabled/unloaded.
Not having the driver loaded, will result in the kernel space apps to use
the registered software implementation of the crypto algorithms.
(3) If your device has Playready application enabled and uses the qcedev module
to access the crypto hardware accelerator, please be informed that for
performance reasons, the CE hardware will need to be dedicated to playready
application. Any other user space or kernel application should be implemented
to use the software implementation of the crypto algorithms.
(NOTE: Please refer to details on the limitations listed in qce/40.txt)

42
Documentation/device-mapper/boot.txt Normal file
View file

@ -0,0 +1,42 @@
Boot time creation of mapped devices
===================================
It is possible to configure a device mapper device to act as the root
device for your system in two ways.
The first is to build an initial ramdisk which boots to a minimal
userspace which configures the device, then pivot_root(8) in to it.
For simple device mapper configurations, it is possible to boot directly
using the following kernel command line:
dm="<name> <uuid> <ro>,table line 1,...,table line n"
name = the name to associate with the device
after boot, udev, if used, will use that name to label
the device node.
uuid = may be 'none' or the UUID desired for the device.
ro = may be "ro" or "rw". If "ro", the device and device table will be
marked read-only.
Each table line may be as normal when using the dmsetup tool except for
two variations:
1. Any use of commas will be interpreted as a newline
2. Quotation marks cannot be escaped and cannot be used without
terminating the dm= argument.
Unless renamed by udev, the device node created will be dm-0 as the
first minor number for the device-mapper is used during early creation.
Example
=======
- Booting to a linear array made up of user-mode linux block devices:
dm="lroot none 0, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \
root=/dev/dm-0
Will boot to a rw dm-linear target of 8192 sectors split across two
block devices identified by their major:minor numbers. After boot, udev
will rename this target to /dev/mapper/lroot (depending on the rules).
No uuid was assigned.

29
Documentation/devicetree/vibrator/dc_vibrator.txt Normal file
View file

@ -0,0 +1,29 @@
Samsung DC vibrator
Required properties:
- compatible: must be "samsung,dc_vibrator".
- dc_vib,motor_type: must be "COINDC".
Optional properties:
- dc_vib,gpio_en: GPIO used for enable motor.
- dc_vib,regulator_name: Regulator name used for enable motor.
- dc_vib,use_qc_regulator: If DC vibraotr VCC is connected with special QCOM
pmic ldo, use this property.
- pinctrl variants.
Examples:
dc_vibrator {
compatible = "samsung,dc_vibrator";
status = "okay";
dc_vib,gpio_en = <&gpio 1 0>;
dc_vib,regulator_name = "VDD_LDO";
dc_vib,use_qc_regulator;
dc_vib,motor_type = "COINDC";
};

9
Documentation/driver-api/i3c/device-driver-api.rst Normal file
View file

@ -0,0 +1,9 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
I3C device driver API
=====================
.. kernel-doc:: include/linux/i3c/device.h
.. kernel-doc:: drivers/i3c/device.c

11
Documentation/driver-api/i3c/index.rst Normal file
View file

@ -0,0 +1,11 @@
.. SPDX-License-Identifier: GPL-2.0
=============
I3C subsystem
=============
.. toctree::
protocol
device-driver-api
master-driver-api

9
Documentation/driver-api/i3c/master-driver-api.rst Normal file
View file

@ -0,0 +1,9 @@
.. SPDX-License-Identifier: GPL-2.0
================================
I3C master controller driver API
================================
.. kernel-doc:: drivers/i3c/master.c
.. kernel-doc:: include/linux/i3c/master.h

Some files were not shown because too many files have changed in this diff Show more