davidlt
/
kernel-ark
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge 'master' into 'os-build'

This commit is contained in:
Fedora Kernel Team 2021-11-03 10:18:58 +00:00
parent 184f72c189 dcd68326d2
commit 17648736e2
4009 changed files with 325615 additions and 79400 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

244
Documentation/ABI/stable/sysfs-driver-mlxreg-io
View File

@ -223,3 +223,247 @@ Description: These files show with which CPLD part numbers and minor
system.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_active_image
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_auth_fail
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_upgrade_fail
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: The files represent BIOS statuses:
bios_active_image: location of current active BIOS image:
0: Top, 1: Bottom.
The reported value should correspond to value expected by OS
in case of BIOS safe mode is 0. This bit is related to Intel
top-swap feature of DualBios on the same flash.
bios_auth_fail: BIOS upgrade is failed because provided BIOS
image is not signed correctly.
bios_upgrade_fail: BIOS upgrade is failed by some other
reason not because authentication. For example due to
physical SPI flash problem.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_enable
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow line cards enable state control.
Expected behavior:
When lc{n}_enable is written 1, related line card is released
from the reset state, when 0 - is hold in reset state.
The files are read/write.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_pwr
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_pwr
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files switching line cards power on and off.
Expected behavior:
When lc{n}_pwr is written 1, related line card is powered
on, when written 0 - powered off.
The files are read/write.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_rst_mask
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_rst_mask
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files clear line card reset bit enforced by ASIC, when it
sets it due to some abnormal ASIC behavior.
Expected behavior:
When lc{n}_rst_mask is written 1, related line card reset bit
is cleared, when written 0 - no effect.
The files are write only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/os_started
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file, when written 1, indicates to programmable devices
that OS is taking control over it.
The file is read/write.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pm_mgmt_en
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file assigns power management control ownership.
When power management control is provided by hardware, hardware
will automatically power off one or more line previously
powered line cards in case system power budget is getting
insufficient. It could be in case when some of power units lost
power good state.
When pm_mgmt_en is written 1, power management control by
software is enabled, 0 - power management control by hardware.
Note that for any setting of pm_mgmt_en attribute hardware will
not allow to power on any new line card in case system power
budget is insufficient.
Same in case software will try to power on several line cards
at once - hardware will power line cards while system has
enough power budget.
Default is 0.
The file is read/write.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu3_on
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu4_on
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files switching power supply units on and off.
Expected behavior:
When psu3_on or psu4_on is written 1, related unit will be
disconnected from the power source, when written 0 - connected.
The files are write only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/shutdown_unlock
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows to unlock ASIC after thermal shutdown event.
When system thermal shutdown is enforced by ASIC, ASIC is
getting locked and after system boot it will not be available.
Software can decide to unlock it by setting this attribute to
1 and then perform system power cycle by setting pwr_cycle
attribute to 1 (power cycle of main power domain).
Before setting shutdown_unlock to 1 it is recommended to
validate that system reboot cause is reset_asic_thermal or
reset_thermal_spc_or_pciesw.
In case shutdown_unlock is not set 1, the only way to release
ASIC from locking - is full system power cycle through the
external power distribution unit.
Default is 1.
The file is read/write.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_pn
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version_min
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which CPLD major and minor versions
and part number has been burned CPLD device on line card.
The files are read only.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_pn
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version_min
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which FPGA major and minor versions
and part number has been burned FPGA device on line card.
The files are read only.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/vpd_wp
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allow to overwrite line card VPD hardware write
protection mode. When attribute is set 1 - write protection is
disabled, when 0 - enabled.
Default is 0.
If the system is in locked-down mode writing this file will not
be allowed.
The purpose if this file is to allow line card VPD burning
during production flow.
The file is read/write.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_aux_pwr_or_ref
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_dc_dc_pwr_fail
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_fpga_not_done
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_from_chassis
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_line_card
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_pwr_off_from_chassis
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show the line reset cause, as following: power
auxiliary outage or power refresh, DC-to-DC power failure, FPGA reset
failed, line card reset failed, power off from chassis.
Value 1 in file means this is reset cause, 0 - otherwise. Only one of
the above causes could be 1 at the same time, representing only last
reset cause.
The files are read only.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld_upgrade_en
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_upgrade_en
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow CPLD and FPGA burning. Value 1 in file means burning
is enabled, 0 - otherwise.
If the system is in locked-down mode writing these files will
not be allowed.
The purpose of these files to allow line card CPLD and FPGA
upgrade through the JTAG daisy-chain.
The files are read/write.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/qsfp_pwr_en
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/pwr_en
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow to power on/off all QSFP ports and whole line card.
The attributes are set 1 for power on, 0 - for power off.
The files are read/write.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/agb_spi_burn_en
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_spi_burn_en
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow gearboxes and FPGA SPI flash burning.
The attributes are set 1 to enable burning, 0 - to disable.
If the system is in locked-down mode writing these files will
not be allowed.
The purpose of these files to allow line card Gearboxes and FPGA
burning during production flow.
The file is read/write.
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/max_power
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/config
Date: October 2021
KernelVersion: 5.16
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files provide the maximum powered required for line card
feeding and line card configuration Id.
The files are read only.

8
Documentation/ABI/testing/ima_policy
View File

@ -22,8 +22,9 @@ Description:
action: measure | dont_measure | appraise | dont_appraise |
audit | hash | dont_hash
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[euid=] [fowner=] [fsname=]]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [fsname=]
[uid=] [euid=] [gid=] [egid=]
[fowner=] [fgroup=]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]] [template=] [permit_directio]
@ -40,7 +41,10 @@ Description:
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
uid:= decimal value
euid:= decimal value
gid:= decimal value
egid:= decimal value
fowner:= decimal value
fgroup:= decimal value
lsm: are LSM specific
option:
appraise_type:= [imasig] [imasig|modsig]

16
Documentation/ABI/testing/sysfs-block
View File

@ -28,6 +28,22 @@ Description:
For more details refer Documentation/admin-guide/iostats.rst
What: /sys/block/<disk>/inflight
Date: October 2009
Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
Description:
Reports the number of I/O requests currently in progress
(pending / in flight) in a device driver. This can be less
than the number of requests queued in the block device queue.
The report contains 2 fields: one for read requests
and one for write requests.
The value type is unsigned int.
Cf. Documentation/block/stat.rst which contains a single value for
requests in flight.
This is related to nr_requests in Documentation/block/queue-sysfs.rst
and for SCSI device also its queue_depth.
What: /sys/block/<disk>/diskseq
Date: February 2021
Contact: Matteo Croce <mcroce@microsoft.com>

259
Documentation/ABI/testing/sysfs-class-thermal Normal file
View File

@ -0,0 +1,259 @@
What: /sys/class/thermal/thermal_zoneX/type
Description:
Strings which represent the thermal zone type.
This is given by thermal zone driver as part of registration.
E.g: "acpitz" indicates it's an ACPI thermal device.
In order to keep it consistent with hwmon sys attribute; this
shouldbe a short, lowercase string, not containing spaces nor
dashes.
RO, Required
What: /sys/class/thermal/thermal_zoneX/temp
Description:
Current temperature as reported by thermal zone (sensor).
Unit: millidegree Celsius
RO, Required
What: /sys/class/thermal/thermal_zoneX/mode
Description:
One of the predefined values in [enabled, disabled].
This file gives information about the algorithm that is
currently managing the thermal zone. It can be either default
kernel based algorithm or user space application.
enabled
enable Kernel Thermal management.
disabled
Preventing kernel thermal zone driver actions upon
trip points so that user application can take full
charge of the thermal management.
RW, Optional
What: /sys/class/thermal/thermal_zoneX/policy
Description:
One of the various thermal governors used for a particular zone.
RW, Required
What: /sys/class/thermal/thermal_zoneX/available_policies
Description:
Available thermal governors which can be used for a
particular zone.
RO, Required
What: /sys/class/thermal/thermal_zoneX/trip_point_Y_temp
Description:
The temperature above which trip point will be fired.
Unit: millidegree Celsius
RO, Optional
What: /sys/class/thermal/thermal_zoneX/trip_point_Y_type
Description:
Strings which indicate the type of the trip point.
E.g. it can be one of critical, hot, passive, `active[0-*]`
for ACPI thermal zone.
RO, Optional
What: /sys/class/thermal/thermal_zoneX/trip_point_Y_hyst
Description:
The hysteresis value for a trip point, represented as an
integer.
Unit: Celsius
RW, Optional
What: /sys/class/thermal/thermal_zoneX/cdevY
Description:
Sysfs link to the thermal cooling device node where the sys I/F
for cooling device throttling control represents.
RO, Optional
What: /sys/class/thermal/thermal_zoneX/cdevY_trip_point
Description:
The trip point in this thermal zone which `cdev[0-*]` is
associated with; -1 means the cooling device is not
associated with any trip point.
RO, Optional
What: /sys/class/thermal/thermal_zoneX/cdevY_weight
Description:
The influence of `cdev[0-*]` in this thermal zone. This value
is relative to the rest of cooling devices in the thermal
zone. For example, if a cooling device has a weight double
than that of other, it's twice as effective in cooling the
thermal zone.
RW, Optional
What: /sys/class/thermal/thermal_zoneX/emul_temp
Description:
Interface to set the emulated temperature method in thermal zone
(sensor). After setting this temperature, the thermal zone may
pass this temperature to platform emulation function if
registered or cache it locally. This is useful in debugging
different temperature threshold and its associated cooling
action. This is write only node and writing 0 on this node
should disable emulation.
Unit: millidegree Celsius
WO, Optional
WARNING:
Be careful while enabling this option on production systems,
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
What: /sys/class/thermal/thermal_zoneX/k_d
Description:
The derivative term of the power allocator governor's PID
controller. For more information see
Documentation/driver-api/thermal/power_allocator.rst
RW, Optional
What: /sys/class/thermal/thermal_zoneX/k_i
Description:
The integral term of the power allocator governor's PID
controller. This term allows the PID controller to compensate
for long term drift. For more information see
Documentation/driver-api/thermal/power_allocator.rst
RW, Optional
What: /sys/class/thermal/thermal_zoneX/k_po
Description:
The proportional term of the power allocator governor's PID
controller during temperature overshoot. Temperature overshoot
is when the current temperature is above the "desired
temperature" trip point. For more information see
Documentation/driver-api/thermal/power_allocator.rst
RW, Optional
What: /sys/class/thermal/thermal_zoneX/k_pu
Description:
The proportional term of the power allocator governor's PID
controller during temperature undershoot. Temperature undershoot
is when the current temperature is below the "desired
temperature" trip point. For more information see
Documentation/driver-api/thermal/power_allocator.rst
RW, Optional
What: /sys/class/thermal/thermal_zoneX/integral_cutoff
Description:
Temperature offset from the desired temperature trip point
above which the integral term of the power allocator
governor's PID controller starts accumulating errors. For
example, if integral_cutoff is 0, then the integral term only
accumulates error when temperature is above the desired
temperature trip point. For more information see
Documentation/driver-api/thermal/power_allocator.rst
Unit: millidegree Celsius
RW, Optional
What: /sys/class/thermal/thermal_zoneX/slope
Description:
The slope constant used in a linear extrapolation model
to determine a hotspot temperature based off the sensor's
raw readings. It is up to the device driver to determine
the usage of these values.
RW, Optional
What: /sys/class/thermal/thermal_zoneX/offset
Description:
The offset constant used in a linear extrapolation model
to determine a hotspot temperature based off the sensor's
raw readings. It is up to the device driver to determine
the usage of these values.
RW, Optional
What: /sys/class/thermal/thermal_zoneX/sustainable_power
Description:
An estimate of the sustained power that can be dissipated by
the thermal zone. Used by the power allocator governor. For
more information see
Documentation/driver-api/thermal/power_allocator.rst
Unit: milliwatts
RW, Optional
What: /sys/class/thermal/cooling_deviceX/type
Description:
String which represents the type of device, e.g:
- for generic ACPI: should be "Fan", "Processor" or "LCD"
- for memory controller device on intel_menlow platform:
should be "Memory controller".
RO, Required
What: /sys/class/thermal/cooling_deviceX/max_state
Description:
The maximum permissible cooling state of this cooling device.
RO, Required
What: /sys/class/thermal/cooling_deviceX/cur_state
Description:
The current cooling state of this cooling device.
The value can any integer numbers between 0 and max_state:
- cur_state == 0 means no cooling
- cur_state == max_state means the maximum cooling.
RW, Required
What: /sys/class/thermal/cooling_deviceX/stats/reset
Description:
Writing any value resets the cooling device's statistics.
WO, Required
What: /sys/class/thermal/cooling_deviceX/stats/time_in_state_ms:
Description:
The amount of time spent by the cooling device in various
cooling states. The output will have "<state> <time>" pair
in each line, which will mean this cooling device spent <time>
msec of time at <state>.
Output will have one line for each of the supported states.
RO, Required
What: /sys/class/thermal/cooling_deviceX/stats/total_trans
Description:
A single positive value showing the total number of times
the state of a cooling device is changed.
RO, Required
What: /sys/class/thermal/cooling_deviceX/stats/trans_table
Description:
This gives fine grained information about all the cooling state
transitions. The cat output here is a two dimensional matrix,
where an entry <i,j> (row i, column j) represents the number
of transitions from State_i to State_j. If the transition
table is bigger than PAGE_SIZE, reading this will return
an -EFBIG error.
RO, Required

4
Documentation/ABI/testing/sysfs-driver-xen-blkback
View File

@ -29,7 +29,7 @@ Description:
What: /sys/module/xen_blkback/parameters/buffer_squeeze_duration_ms
Date: December 2019
KernelVersion: 5.6
Contact: SeongJae Park <sjpark@amazon.de>
Contact: SeongJae Park <sj@kernel.org>
Description:
When memory pressure is reported to blkback this option
controls the duration in milliseconds that blkback will not
@ -39,7 +39,7 @@ Description:
What: /sys/module/xen_blkback/parameters/feature_persistent
Date: September 2020
KernelVersion: 5.10
Contact: SeongJae Park <sjpark@amazon.de>
Contact: SeongJae Park <sj@kernel.org>
Description:
Whether to enable the persistent grants feature or not. Note
that this option only takes effect on newly created backends.

2
Documentation/ABI/testing/sysfs-driver-xen-blkfront
View File

@ -12,7 +12,7 @@ Description:
What: /sys/module/xen_blkfront/parameters/feature_persistent
Date: September 2020
KernelVersion: 5.10
Contact: SeongJae Park <sjpark@amazon.de>
Contact: SeongJae Park <sj@kernel.org>
Description:
Whether to enable the persistent grants feature or not. Note
that this option only takes effect on newly created frontends.

60
Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
View File

@ -1,55 +1,71 @@
What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
Date: Apr 2021
KernelVersion: 5.13
Contact: "perry.yuan@dell.com>"
Contact: "<perry.yuan@dell.com>"
Description:
Display which dell hardware level privacy devices are supported
“Dell Privacy” is a set of HW, FW, and SW features to enhance
Dell’s commitment to platform privacy for MIC, Camera, and
ePrivacy screens.
The supported hardware privacy devices are:
Attributes:
Microphone Mute:
Attributes:
Microphone Mute:
Identifies the local microphone can be muted by hardware, no applications
is available to capture system mic sound
Camera Shutter:
Camera Shutter:
Identifies camera shutter controlled by hardware, which is a micromechanical
shutter assembly that is built onto the camera module to block capturing images
from outside the laptop
supported:
Values:
supported:
The privacy device is supported by this system
unsupported:
unsupported:
The privacy device is not supported on this system
For example to check which privacy devices are supported:
For example to check which privacy devices are supported::
# cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
[Microphone Mute] [supported]
[Camera Shutter] [supported]
[ePrivacy Screen] [unsupported]
# cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
[Microphone Mute] [supported]
[Camera Shutter] [supported]
[ePrivacy Screen] [unsupported]
What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state
Date: Apr 2021
KernelVersion: 5.13
Contact: "perry.yuan@dell.com>"
Contact: "<perry.yuan@dell.com>"
Description:
Allow user space to check current dell privacy device state.
Describes the Device State class exposed by BIOS which can be
consumed by various applications interested in knowing the Privacy
feature capabilities
Attributes:
muted:
Identifies the privacy device is turned off and cannot send stream to OS applications
unmuted:
Identifies the privacy device is turned on ,audio or camera driver can get
stream from mic and camera module to OS applications
Attributes:
Microphone:
Identifies the local microphone can be muted by hardware, no applications
is available to capture system mic sound
For example to check all supported current privacy device states:
Camera Shutter:
Identifies camera shutter controlled by hardware, which is a micromechanical
shutter assembly that is built onto the camera module to block capturing images
from outside the laptop
# cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state
[Microphone] [unmuted]
[Camera Shutter] [unmuted]
Values:
muted:
Identifies the privacy device is turned off
and cannot send stream to OS applications
unmuted:
Identifies the privacy device is turned on,
audio or camera driver can get stream from mic
and camera module to OS applications
For example to check all supported current privacy device states::
# cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state
[Microphone] [unmuted]
[Camera Shutter] [unmuted]

2
Documentation/ABI/testing/sysfs-platform-intel-pmc
View File

@ -11,8 +11,10 @@ Description:
to take effect.
Display global reset setting bits for PMC.
* bit 31 - global reset is locked
* bit 20 - global reset is set
Writing bit 20 value to the etr3 will induce
a platform "global reset" upon consequent platform reset,
in case the register is not locked.

174
Documentation/ABI/testing/sysfs-timecard Normal file
View File

@ -0,0 +1,174 @@
What: /sys/class/timecard/
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This directory contains files and directories
providing a standardized interface to the ancillary
features of the OpenCompute timecard.
What: /sys/class/timecard/ocpN/
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This directory contains the attributes of the Nth timecard
registered.
What: /sys/class/timecard/ocpN/available_clock_sources
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) The list of available time sources that the PHC
uses for clock adjustments.
==== =================================================
NONE no adjustments
PPS adjustments come from the PPS1 selector (default)
TOD adjustments from the GNSS/TOD module
IRIG adjustments from external IRIG-B signal
DCF adjustments from external DCF signal
==== =================================================
What: /sys/class/timecard/ocpN/available_sma_inputs
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Set of available destinations (sinks) for a SMA
input signal.
===== ================================================
10Mhz signal is used as the 10Mhz reference clock
PPS1 signal is sent to the PPS1 selector
PPS2 signal is sent to the PPS2 selector
TS1 signal is sent to timestamper 1
TS2 signal is sent to timestamper 2
IRIG signal is sent to the IRIG-B module
DCF signal is sent to the DCF module
===== ================================================
What: /sys/class/timecard/ocpN/available_sma_outputs
Date: May 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Set of available sources for a SMA output signal.
===== ================================================
10Mhz output is from the 10Mhz reference clock
PHC output PPS is from the PHC clock
MAC output PPS is from the Miniature Atomic Clock
GNSS output PPS is from the GNSS module
GNSS2 output PPS is from the second GNSS module
IRIG output is from the PHC, in IRIG-B format
DCF output is from the PHC, in DCF format
===== ================================================
What: /sys/class/timecard/ocpN/clock_source
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) Contains the current synchronization source used by
the PHC. May be changed by writing one of the listed
values from the available_clock_sources attribute set.
What: /sys/class/timecard/ocpN/gnss_sync
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Indicates whether a valid GNSS signal is received,
or when the signal was lost.
What: /sys/class/timecard/ocpN/i2c
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This optional attribute links to the associated i2c device.
What: /sys/class/timecard/ocpN/irig_b_mode
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) An integer from 0-7 indicating the timecode format
of the IRIG-B output signal: B00<n>
What: /sys/class/timecard/ocpN/pps
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This optional attribute links to the associated PPS device.
What: /sys/class/timecard/ocpN/ptp
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This attribute links to the associated PTP device.
What: /sys/class/timecard/ocpN/serialnum
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Provides the serial number of the timecard.
What: /sys/class/timecard/ocpN/sma1
What: /sys/class/timecard/ocpN/sma2
What: /sys/class/timecard/ocpN/sma3
What: /sys/class/timecard/ocpN/sma4
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) These attributes specify the direction of the signal
on the associated SMA connectors, and also the signal sink
or source.
The display format of the attribute is a space separated
list of signals, prefixed by the input/output direction.
The signal direction may be changed (if supported) by
prefixing the signal list with either "in:" or "out:".
If neither prefix is present, then the direction is unchanged.
The output signal may be changed by writing one of the listed
values from the available_sma_outputs attribute set.
The input destinations may be changed by writing multiple
values from the available_sma_inputs attribute set,
separated by spaces. If there are duplicated input
destinations between connectors, the lowest numbered SMA
connector is given priority.
Note that not all input combinations may make sense.
The 10Mhz reference clock input is currently only valid
on SMA1 and may not be combined with other destination sinks.
What: /sys/class/timecard/ocpN/ts_window_adjust
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) When retrieving the PHC with the PTP SYS_OFFSET_EXTENDED
ioctl, a system timestamp is made before and after the PHC
time is retrieved. The midpoint between the two system
timestamps is usually taken to be the SYS time associated
with the PHC time. This estimate may be wrong, as it depends
on PCI latencies, and when the PHC time was latched
The attribute value reduces the end timestamp by the given
number of nanoseconds, so the computed midpoint matches the
retrieved PHC time.
The initial value is set based on measured PCI latency and
the estimated point where the FPGA latches the PHC time. This
value may be changed by writing an unsigned integer.
What: /sys/class/timecard/ocpN/ttyGNSS
What: /sys/class/timecard/ocpN/ttyGNSS2
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: These optional attributes link to the TTY serial ports
associated with the GNSS devices.
What: /sys/class/timecard/ocpN/ttyMAC
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This optional attribute links to the TTY serial port
associated with the Miniature Atomic Clock.
What: /sys/class/timecard/ocpN/ttyNMEA
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: This optional attribute links to the TTY serial port
which outputs the PHC time in NMEA ZDA format.
What: /sys/class/timecard/ocpN/utc_tai_offset
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) The DCF and IRIG output signals are in UTC, while the
TimeCard operates on TAI. This attribute allows setting the
offset in seconds, which is added to the TAI timebase for
these formats.
The offset may be changed by writing an unsigned integer.

10
Documentation/admin-guide/cgroup-v2.rst
View File

@ -2318,6 +2318,16 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
Limits can be set higher than the capacity value in the misc.capacity
file.
misc.events
A read-only flat-keyed file which exists on non-root cgroups. The
following entries are defined. Unless specified otherwise, a value
change in this file generates a file modified event. All fields in
this file are hierarchical.
max
The number of times the cgroup's resource usage was
about to go over the max boundary.
Migration and Ownership
~~~~~~~~~~~~~~~~~~~~~~~

15
Documentation/admin-guide/kernel-parameters.txt
View File

@ -2353,7 +2353,14 @@
[KVM] Controls how many 4KiB pages are periodically zapped
back to huge pages. 0 disables the recovery, otherwise if
the value is N KVM will zap 1/Nth of the 4KiB pages every
minute. The default is 60.
period (see below). The default is 60.
kvm.nx_huge_pages_recovery_period_ms=
[KVM] Controls the time period at which KVM zaps 4KiB pages
back to huge pages. If the value is a non-zero N, KVM will
zap a portion (see ratio above) of the pages every N msecs.
If the value is 0 (the default), KVM will pick a period based
on the ratio, such that a page is zapped after 1 hour on average.
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
Default is 1 (enabled)
@ -2365,6 +2372,8 @@
kvm-arm.mode=
[KVM,ARM] Select one of KVM/arm64's modes of operation.
none: Forcefully disable KVM.
nvhe: Standard nVHE-based mode, without support for
protected guests.
@ -2372,7 +2381,9 @@
state is kept private from the host.
Not valid if the kernel is running in EL2.
Defaults to VHE/nVHE based on hardware support.
Defaults to VHE/nVHE based on hardware support. Setting
mode to "protected" will disable kexec and hibernation
for the host.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0

22
Documentation/admin-guide/mm/pagemap.rst
View File

@ -196,6 +196,28 @@ you can go through every map in the process, find the PFNs, look those up
in kpagecount, and tally up the number of pages that are only referenced
once.
Exceptions for Shared Memory
============================
Page table entries for shared pages are cleared when the pages are zapped or
swapped out. This makes swapped out pages indistinguishable from never-allocated
ones.
In kernel space, the swap location can still be retrieved from the page cache.
However, values stored only on the normal PTE get lost irretrievably when the
page is swapped out (i.e. SOFT_DIRTY).
In user space, whether the page is present, swapped or none can be deduced with
the help of lseek and/or mincore system calls.
lseek() can differentiate between accessed pages (present or swapped out) and
holes (none/non-allocated) by specifying the SEEK_DATA flag on the file where
the pages are backed. For anonymous shared pages, the file can be found in
``/proc/pid/map_files/``.
mincore() can differentiate between pages in memory (present, including swap
cache) and out of memory (swapped out or none/non-allocated).
Other notes
===========

2
Documentation/admin-guide/ramoops.rst
View File

@ -69,7 +69,7 @@ Setting the ramoops parameters can be done in several different manners:
mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1
B. Use Device Tree bindings, as described in
``Documentation/devicetree/bindings/reserved-memory/ramoops.txt``.
``Documentation/devicetree/bindings/reserved-memory/ramoops.yaml``.
For example::
reserved-memory {

2
Documentation/admin-guide/spkguide.txt
View File

@ -543,7 +543,7 @@ As mentioned earlier, Speakup can either be completely compiled into the
kernel, with the exception of the help module, or it can be compiled as
a series of modules. When compiled as modules, Speakup will only be
able to speak some of the bootup messages if your system administrator
has configured the system to load the modules at boo time. The modules
has configured the system to load the modules at boot time. The modules
can be loaded after the file systems have been checked and mounted, or
from an initrd. There is a third possibility. Speakup can be compiled
with some components built into the kernel, and others as modules. As

19
Documentation/arm/marvell.rst
View File

@ -21,6 +21,7 @@ Orion family
- Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf
- Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf
- User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf
- Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf
- 88F5281
- Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
@ -212,6 +213,7 @@ EBU Armada family ARMv8
arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
- 88F6040 (AP806 Quad 600 MHz + one CP110)
- 88F7020 (AP806 Dual + one CP110)
- 88F7040 (AP806 Quad + one CP110)
@ -243,6 +245,23 @@ EBU Armada family ARMv8
Device tree files:
arch/arm64/boot/dts/marvell/armada-80*
Octeon TX2 CN913x Flavors:
- CN9130 (AP807 Quad + one internal CP115)
- CN9131 (AP807 Quad + one internal CP115 + one external CP115 / 88F8215)
- CN9132 (AP807 Quad + one internal CP115 + two external CP115 / 88F8215)
Core:
ARM Cortex A72
Homepage:
https://web.archive.org/web/20200803150818/https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-tx2/octeon-tx2-cn9130.html
Product Brief:
https://web.archive.org/web/20200803150818/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-infrastructure-processors-octeon-tx2-cn913x-product-brief-2020-02.pdf
Device tree files:
arch/arm64/boot/dts/marvell/cn913*
Avanta family
-------------

2
Documentation/asm-annotations.rst
View File

@ -64,7 +64,7 @@ macros, it was decided that brand new macros should be introduced instead::
of importing all the crappy, historic, essentially randomly chosen
debug symbol macro names from the binutils and older kernels?
.. _discussion: https://lkml.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz
.. _discussion: https://lore.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz
Macros Description
------------------

9
Documentation/block/queue-sysfs.rst
View File

@ -40,10 +40,11 @@ discard_max_hw_bytes (RO)
-------------------------
Devices that support discard functionality may have internal limits on
the number of bytes that can be trimmed or unmapped in a single operation.
The discard_max_bytes parameter is set by the device driver to the maximum
number of bytes that can be discarded in a single operation. Discard
requests issued to the device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support discard functionality.
The `discard_max_hw_bytes` parameter is set by the device driver to the
maximum number of bytes that can be discarded in a single operation.
Discard requests issued to the device must not exceed this limit.
A `discard_max_hw_bytes` value of 0 means that the device does not support
discard functionality.
discard_max_bytes (RW)
----------------------

92
Documentation/bpf/bpf_licensing.rst Normal file
View File

@ -0,0 +1,92 @@
=============
BPF licensing
=============
Background
==========
* Classic BPF was BSD licensed
"BPF" was originally introduced as BSD Packet Filter in
http://www.tcpdump.org/papers/bpf-usenix93.pdf. The corresponding instruction
set and its implementation came from BSD with BSD license. That original
instruction set is now known as "classic BPF".
However an instruction set is a specification for machine-language interaction,
similar to a programming language. It is not a code. Therefore, the
application of a BSD license may be misleading in a certain context, as the
instruction set may enjoy no copyright protection.
* eBPF (extended BPF) instruction set continues to be BSD
In 2014, the classic BPF instruction set was significantly extended. We
typically refer to this instruction set as eBPF to disambiguate it from cBPF.
The eBPF instruction set is still BSD licensed.
Implementations of eBPF
=======================
Using the eBPF instruction set requires implementing code in both kernel space
and user space.
In Linux Kernel
---------------
The reference implementations of the eBPF interpreter and various just-in-time
compilers are part of Linux and are GPLv2 licensed. The implementation of
eBPF helper functions is also GPLv2 licensed. Interpreters, JITs, helpers,
and verifiers are called eBPF runtime.
In User Space
-------------
There are also implementations of eBPF runtime (interpreter, JITs, helper
functions) under
Apache2 (https://github.com/iovisor/ubpf),
MIT (https://github.com/qmonnet/rbpf), and
BSD (https://github.com/DPDK/dpdk/blob/main/lib/librte_bpf).
In HW
-----
The HW can choose to execute eBPF instruction natively and provide eBPF runtime
in HW or via the use of implementing firmware with a proprietary license.
In other operating systems
--------------------------
Other kernels or user space implementations of eBPF instruction set and runtime
can have proprietary licenses.
Using BPF programs in the Linux kernel
======================================
Linux Kernel (while being GPLv2) allows linking of proprietary kernel modules
under these rules:
Documentation/process/license-rules.rst
When a kernel module is loaded, the linux kernel checks which functions it
intends to use. If any function is marked as "GPL only," the corresponding
module or program has to have GPL compatible license.
Loading BPF program into the Linux kernel is similar to loading a kernel
module. BPF is loaded at run time and not statically linked to the Linux
kernel. BPF program loading follows the same license checking rules as kernel
modules. BPF programs can be proprietary if they don't use "GPL only" BPF
helper functions.
Further, some BPF program types - Linux Security Modules (LSM) and TCP
Congestion Control (struct_ops), as of Aug 2021 - are required to be GPL
compatible even if they don't use "GPL only" helper functions directly. The
registration step of LSM and TCP congestion control modules of the Linux
kernel is done through EXPORT_SYMBOL_GPL kernel functions. In that sense LSM
and struct_ops BPF programs are implicitly calling "GPL only" functions.
The same restriction applies to BPF programs that call kernel functions
directly via unstable interface also known as "kfunc".
Packaging BPF programs with user space applications
====================================================
Generally, proprietary-licensed applications and GPL licensed BPF programs
written for the Linux kernel in the same package can co-exist because they are
separate executable processes. This applies to both cBPF and eBPF programs.

29
Documentation/bpf/btf.rst
View File

@ -85,6 +85,7 @@ sequentially and type id is assigned to each recognized type starting from id
#define BTF_KIND_VAR 14 /* Variable */
#define BTF_KIND_DATASEC 15 /* Section */
#define BTF_KIND_FLOAT 16 /* Floating point */
#define BTF_KIND_DECL_TAG 17 /* Decl Tag */
Note that the type section encodes debug info, not just pure types.
``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram.
@ -106,7 +107,7 @@ Each type contains the following common data::
* "size" tells the size of the type it is describing.
*
* "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT,
* FUNC and FUNC_PROTO.
* FUNC, FUNC_PROTO and DECL_TAG.
* "type" is a type_id referring to another type.
*/
union {
@ -465,6 +466,32 @@ map definition.
No additional type data follow ``btf_type``.
2.2.17 BTF_KIND_DECL_TAG
~~~~~~~~~~~~~~~~~~~~~~~~
``struct btf_type`` encoding requirement:
* ``name_off``: offset to a non-empty string
* ``info.kind_flag``: 0
* ``info.kind``: BTF_KIND_DECL_TAG
* ``info.vlen``: 0
* ``type``: ``struct``, ``union``, ``func``, ``var`` or ``typedef``
``btf_type`` is followed by ``struct btf_decl_tag``.::
struct btf_decl_tag {
__u32 component_idx;
};
The ``name_off`` encodes btf_decl_tag attribute string.
The ``type`` should be ``struct``, ``union``, ``func``, ``var`` or ``typedef``.
For ``var`` or ``typedef`` type, ``btf_decl_tag.component_idx`` must be ``-1``.
For the other three types, if the btf_decl_tag attribute is
applied to the ``struct``, ``union`` or ``func`` itself,
``btf_decl_tag.component_idx`` must be ``-1``. Otherwise,
the attribute is applied to a ``struct``/``union`` member or
a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a
valid index (starting from 0) pointing to a member or an argument.
3. BTF Kernel API
*****************

9
Documentation/bpf/index.rst
View File

@ -82,6 +82,15 @@ Testing and debugging BPF
s390
Licensing
=========
.. toctree::
:maxdepth: 1
bpf_licensing
Other
=====

40
Documentation/bpf/libbpf/libbpf_naming_convention.rst
View File

@ -150,6 +150,46 @@ mirror of the mainline's version of libbpf for a stand-alone build.
However, all changes to libbpf's code base must be upstreamed through
the mainline kernel tree.
API documentation convention
============================
The libbpf API is documented via comments above definitions in
header files. These comments can be rendered by doxygen and sphinx
for well organized html output. This section describes the
convention in which these comments should be formated.
Here is an example from btf.h:
.. code-block:: c
/**
* @brief **btf__new()** creates a new instance of a BTF object from the raw
* bytes of an ELF's BTF section
* @param data raw bytes
* @param size number of bytes passed in `data`
* @return new BTF object instance which has to be eventually freed with
* **btf__free()**
*
* On error, error-code-encoded-as-pointer is returned, not a NULL. To extract
* error code from such a pointer `libbpf_get_error()` should be used. If
* `libbpf_set_strict_mode(LIBBPF_STRICT_CLEAN_PTRS)` is enabled, NULL is
* returned on error instead. In both cases thread-local `errno` variable is
* always set to error code as well.
*/
The comment must start with a block comment of the form '/\*\*'.
The documentation always starts with a @brief directive. This line is a short
description about this API. It starts with the name of the API, denoted in bold
like so: **api_name**. Please include an open and close parenthesis if this is a
function. Follow with the short description of the API. A longer form description
can be added below the last directive, at the bottom of the comment.
Parameters are denoted with the @param directive, there should be one for each
parameter. If this is a function with a non-void return, use the @return directive
to document it.
License
-------------------

3
Documentation/conf.py
View File

@ -353,6 +353,9 @@ latex_elements = {
\\setsansfont{DejaVu Sans}
\\setromanfont{DejaVu Serif}
\\setmonofont{DejaVu Sans Mono}
% Adjust \\headheight for fancyhdr
\\addtolength{\\headheight}{1.6pt}
\\addtolength{\\topmargin}{-1.6pt}
''',
}

2
Documentation/core-api/printk-formats.rst
View File

@ -580,7 +580,7 @@ Flags bitfields such as page flags, gfp_flags
::
%pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff
%pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff)
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
%pGv read|exec|mayread|maywrite|mayexec|denywrite

21
Documentation/core-api/workqueue.rst
View File

@ -216,10 +216,6 @@ resources, scheduled and executed.
This flag is meaningless for unbound wq.
Note that the flag ``WQ_NON_REENTRANT`` no longer exists as all
workqueues are now non-reentrant - any work item is guaranteed to be
executed by at most one worker system-wide at any given time.
``max_active``
--------------
@ -391,6 +387,23 @@ the stack trace of the offending worker thread. ::
The work item's function should be trivially visible in the stack
trace.
Non-reentrance Conditions
=========================
Workqueue guarantees that a work item cannot be re-entrant if the following
conditions hold after a work item gets queued:
1. The work function hasn't been changed.
2. No one queues the work item to another workqueue.
3. The work item hasn't been reinitiated.
In other words, if the above conditions hold, the work item is guaranteed to be
executed by at most one worker system-wide at any given time.
Note that requeuing the work item (to the same queue) in the self function
doesn't break these conditions, so it's safe to do. Otherwise, caution is
required when breaking the conditions inside a work function.
Kernel Inline Documentations Reference
======================================

81
Documentation/dev-tools/checkpatch.rst
View File

@ -710,6 +710,39 @@ Indentation and Line Breaks
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings
**SPLIT_STRING**
Quoted strings that appear as messages in userspace and can be
grepped, should not be split across multiple lines.
See: https://lore.kernel.org/lkml/20120203052727.GA15035@leaf/
**MULTILINE_DEREFERENCE**
A single dereferencing identifier spanned on multiple lines like::
struct_identifier->member[index].
member = <foo>;
is generally hard to follow. It can easily lead to typos and so makes
the code vulnerable to bugs.
If fixing the multiple line dereferencing leads to an 80 column
violation, then either rewrite the code in a more simple way or if the
starting part of the dereferencing identifier is the same and used at
multiple places then store it in a temporary variable, and use that
temporary variable only at all the places. For example, if there are
two dereferencing identifiers::
member1->member2->member3.foo1;
member1->member2->member3.foo2;
then store the member1->member2->member3 part in a temporary variable.
It not only helps to avoid the 80 column violation but also reduces
the program size by removing the unnecessary dereferences.
But if none of the above methods work then ignore the 80 column
violation because it is much easier to read a dereferencing identifier
on a single line.
**TRAILING_STATEMENTS**
Trailing statements (for example after any conditional) should be
on the next line.
@ -845,6 +878,38 @@ Macros, Attributes and Symbols
Use the `fallthrough;` pseudo keyword instead of
`/* fallthrough */` like comments.
**TRAILING_SEMICOLON**
Macro definition should not end with a semicolon. The macro
invocation style should be consistent with function calls.
This can prevent any unexpected code paths::
#define MAC do_something;
If this macro is used within a if else statement, like::
if (some_condition)
MAC;
else
do_something;
Then there would be a compilation error, because when the macro is
expanded there are two trailing semicolons, so the else branch gets
orphaned.
See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/
**SINGLE_STATEMENT_DO_WHILE_MACRO**
For the multi-statement macros, it is necessary to use the do-while
loop to avoid unpredictable code paths. The do-while loop helps to
group the multiple statements into a single one so that a
function-like macro can be used as a function only.
But for the single statement macros, it is unnecessary to use the
do-while loop. Although the code is syntactically correct but using
the do-while loop is redundant. So remove the do-while loop for single
statement macros.
**WEAK_DECLARATION**
Using weak declarations like __attribute__((weak)) or __weak
can have unintended link defects. Avoid using them.
@ -920,6 +985,11 @@ Functions and Variables
Your compiler (or rather your loader) automatically does
it for you.
**MULTIPLE_ASSIGNMENTS**
Multiple assignments on a single line makes the code unnecessarily
complicated. So on a single line assign value to a single variable
only, this makes the code more readable and helps avoid typos.
**RETURN_PARENTHESES**
return is not a function and as such doesn't need parentheses::
@ -957,6 +1027,17 @@ Permissions
Permission bits should use 4 digit octal permissions (like 0700 or 0444).
Avoid using any other base like decimal.
**SYMBOLIC_PERMS**
Permission bits in the octal form are more readable and easier to
understand than their symbolic counterparts because many command-line
tools use this notation. Experienced kernel developers have been using
these traditional Unix permission bits for decades and so they find it
easier to understand the octal notation than the symbolic macros.
For example, it is harder to read S_IWUSR|S_IRUGO than 0644, which
obscures the developer's intent rather than clarifying it.
See: https://lore.kernel.org/lkml/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com/
Spacing and Brackets
--------------------

11
Documentation/dev-tools/kunit/running_tips.rst
View File

@ -25,8 +25,8 @@ It can be handy to create a bash function like:
Running a subset of tests
-------------------------
``kunit.py run`` accepts an optional glob argument to filter tests. Currently
this only matches against suite names, but this may change in the future.
``kunit.py run`` accepts an optional glob argument to filter tests. The format
is ``"<suite_glob>[.test_glob]"``.
Say that we wanted to run the sysctl tests, we could do so via:
@ -35,6 +35,13 @@ Say that we wanted to run the sysctl tests, we could do so via:
$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run 'sysctl*'
We can filter down to just the "write" tests via:
.. code-block:: bash
$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run 'sysctl*.*write*'
We're paying the cost of building more tests than we need this way, but it's
easier than fiddling with ``.kunitconfig`` files or commenting out
``kunit_suite``'s.

20
Documentation/devicetree/bindings/Makefile
View File

@ -9,6 +9,11 @@ DT_SCHEMA_MIN_VERSION = 2021.2.1
PHONY += check_dtschema_version
check_dtschema_version:
@which $(DT_DOC_CHECKER) >/dev/null || \
{ echo "Error: '$(DT_DOC_CHECKER)' not found!" >&2; \
echo "Ensure dtschema python package is installed and in your PATH." >&2; \
echo "Current PATH is:" >&2; \
echo "$$PATH" >&2; false; }
@{ echo $(DT_SCHEMA_MIN_VERSION); \
$(DT_DOC_CHECKER) --version 2>/dev/null || echo 0; } | sort -Vc >/dev/null || \
{ echo "ERROR: dtschema minimum version is v$(DT_SCHEMA_MIN_VERSION)" >&2; false; }
@ -22,13 +27,20 @@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE
# Use full schemas when checking %.example.dts
DT_TMP_SCHEMA := $(obj)/processed-schema-examples.json
find_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
-name 'processed-schema*' ! \
-name '*.example.dt.yaml' \)
ifeq ($(DT_SCHEMA_FILES),)
find_cmd = $(find_all_cmd)
else
find_cmd = echo $(addprefix $(srctree)/, $(DT_SCHEMA_FILES))
endif
quiet_cmd_yamllint = LINT $(src)
cmd_yamllint = ($(find_cmd) | \
xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true
xargs -n200 -P$$(nproc) \
$(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true
quiet_cmd_chk_bindings = CHKDT $@
cmd_chk_bindings = ($(find_cmd) | \
@ -38,7 +50,7 @@ quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
$(if $(DT_MK_SCHEMA_FLAGS), \
printf '%s\n' $(real-prereqs), \
$(find_cmd)) > $$f ; \
$(find_all_cmd)) > $$f ; \
$(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \
rm -f $$f
@ -48,7 +60,7 @@ define rule_chkdt
$(call cmd,mk_schema)
endef
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_cmd)))
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
override DTC_FLAGS := \
-Wno-avoid_unnecessary_addr_size \

216
Documentation/devicetree/bindings/arm/arm,cci-400.yaml Normal file
View File

@ -0,0 +1,216 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM CCI Cache Coherent Interconnect Device Tree Binding
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
description: >
ARM multi-cluster systems maintain intra-cluster coherency through a cache
coherent interconnect (CCI) that is capable of monitoring bus transactions
and manage coherency, TLB invalidations and memory barriers.
It allows snooping and distributed virtual memory message broadcast across
clusters, through memory mapped interface, with a global control register
space and multiple sets of interface control registers, one per slave
interface.
properties:
$nodename:
pattern: "^cci(@[0-9a-f]+)?$"
compatible:
enum:
- arm,cci-400
- arm,cci-500
- arm,cci-550
reg:
maxItems: 1
description: >
Specifies base physical address of CCI control registers common to all
interfaces.
"#address-cells": true
"#size-cells": true
ranges: true
patternProperties:
"^slave-if@[0-9a-f]+$":
type: object
properties:
compatible:
const: arm,cci-400-ctrl-if
interface-type:
enum:
- ace
- ace-lite
reg:
maxItems: 1
required:
- compatible
- interface-type
- reg
additionalProperties: false
"^pmu@[0-9a-f]+$":
type: object
properties:
compatible:
oneOf:
- const: arm,cci-400-pmu,r0
- const: arm,cci-400-pmu,r1
- const: arm,cci-400-pmu
deprecated: true
description: >
Permitted only where OS has secure access to CCI registers
- const: arm,cci-500-pmu,r0
- const: arm,cci-550-pmu,r0
interrupts:
minItems: 1
maxItems: 8
description: >
List of counter overflow interrupts, one per counter. The interrupts
must be specified starting with the cycle counter overflow interrupt,
followed by counter0 overflow interrupt, counter1 overflow
interrupt,... ,counterN overflow interrupt.
The CCI PMU has an interrupt signal for each counter. The number of
interrupts must be equal to the number of counters.
reg:
maxItems: 1
required:
- compatible
- interrupts
- reg
additionalProperties: false
required:
- "#address-cells"
- "#size-cells"
- compatible
- ranges
- reg
additionalProperties: false
examples:
- |
/ {
#address-cells = <2>;
#size-cells = <2>;
compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress";
model = "V2P-CA15_CA7";
arm,hbi = <0x249>;
interrupt-parent = <&gic>;
/*
* This CCI node corresponds to a CCI component whose control
* registers sits at address 0x000000002c090000.
*
* CCI slave interface @0x000000002c091000 is connected to dma
* controller dma0.
*
* CCI slave interface @0x000000002c094000 is connected to CPUs
* {CPU0, CPU1};
*
* CCI slave interface @0x000000002c095000 is connected to CPUs
* {CPU2, CPU3};
*/
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x1>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x100>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x101>;
};
};
dma0: dma@3000000 {
/* compatible = "arm,pl330", "arm,primecell"; */
cci-control-port = <&cci_control0>;
reg = <0x0 0x3000000 0x0 0x1000>;
interrupts = <10>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
cci@2c090000 {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x2c090000 0 0x1000>;
ranges = <0x0 0x0 0x2c090000 0x10000>;
cci_control0: slave-if@1000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace-lite";
reg = <0x1000 0x1000>;
};
cci_control1: slave-if@4000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x4000 0x1000>;
};
cci_control2: slave-if@5000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x5000 0x1000>;
};
pmu@9000 {
compatible = "arm,cci-400-pmu";
reg = <0x9000 0x5000>;
interrupts = <0 101 4>,
<0 102 4>,
<0 103 4>,
<0 104 4>,
<0 105 4>;
};
};
};
...

46
Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
View File

@ -119,22 +119,6 @@ properties:
- const: arm,foundation-aarch64
- const: arm,vexpress
arm,hbi:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
arm,vexpress,site:
description: As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
For this reason the root node and main motherboard node must define this
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
$ref: '/schemas/types.yaml#/definitions/uint32'
minimum: 0
maximum: 15
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
@ -154,9 +138,9 @@ patternProperties:
description: Static Memory Bus (SMB) node, if this exists it describes
the connection between the motherboard and any tiles. Sometimes the
compatible is placed directly under this node, sometimes it is placed
in a subnode named "motherboard". Sometimes the compatible includes
in a subnode named "motherboard-bus". Sometimes the compatible includes
"arm,vexpress,v2?-p1" sometimes (on software models) is is just
"simple-bus". If the compatible is placed in the "motherboard" node,
"simple-bus". If the compatible is placed in the "motherboard-bus" node,
it is stricter and always has two compatibles.
type: object
$ref: '/schemas/simple-bus.yaml'
@ -170,7 +154,9 @@ patternProperties:
- arm,vexpress,v2p-p1
- const: simple-bus
- const: simple-bus
motherboard:
patternProperties:
'^motherboard-bus@':
type: object
description: The motherboard description provides a single "motherboard"
node using 2 address cells corresponding to the Static Memory Bus
@ -183,6 +169,8 @@ patternProperties:
const: 2
"#size-cells":
const: 1
ranges: true
compatible:
items:
- enum:
@ -196,8 +184,28 @@ patternProperties:
- rs1
- rs2
arm,hbi:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
arm,vexpress,site:
description: As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
For this reason the root node and main motherboard node must define this
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
$ref: '/schemas/types.yaml#/definitions/uint32'
minimum: 0
maximum: 15
required:
- compatible
additionalProperties:
type: object
required:
- compatible

38
Documentation/devicetree/bindings/arm/cci-control-port.yaml Normal file
View File

@ -0,0 +1,38 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/cci-control-port.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: CCI Interconnect Bus Masters binding
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
description: |
Masters in the device tree connected to a CCI port (inclusive of CPUs
and their cpu nodes).
select: true
properties:
cci-control-port:
$ref: /schemas/types.yaml#/definitions/phandle
additionalProperties: true
examples:
- |
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a15";
device_type = "cpu";
cci-control-port = <&cci_control1>;
reg = <0>;
};
};
...

224
Documentation/devicetree/bindings/arm/cci.txt
View File

@ -1,224 +0,0 @@
=======================================================
ARM CCI cache coherent interconnect binding description
=======================================================
ARM multi-cluster systems maintain intra-cluster coherency through a
cache coherent interconnect (CCI) that is capable of monitoring bus
transactions and manage coherency, TLB invalidations and memory barriers.
It allows snooping and distributed virtual memory message broadcast across
clusters, through memory mapped interface, with a global control register
space and multiple sets of interface control registers, one per slave
interface.
* CCI interconnect node
Description: Describes a CCI cache coherent Interconnect component
Node name must be "cci".
Node's parent must be the root node /, and the address space visible
through the CCI interconnect is the same as the one seen from the
root node (ie from CPUs perspective as per DT standard).
Every CCI node has to define the following properties:
- compatible
Usage: required
Value type: <string>
Definition: must contain one of the following:
"arm,cci-400"
"arm,cci-500"
"arm,cci-550"
- reg
Usage: required
Value type: Integer cells. A register entry, expressed as a pair
of cells, containing base and size.
Definition: A standard property. Specifies base physical
address of CCI control registers common to all
interfaces.
- ranges:
Usage: required
Value type: Integer cells. An array of range entries, expressed
as a tuple of cells, containing child address,
parent address and the size of the region in the
child address space.
Definition: A standard property. Follow rules in the Devicetree
Specification for hierarchical bus addressing. CCI
interfaces addresses refer to the parent node
addressing scheme to declare their register bases.
CCI interconnect node can define the following child nodes:
- CCI control interface nodes
Node name must be "slave-if".
Parent node must be CCI interconnect node.
A CCI control interface node must contain the following
properties:
- compatible
Usage: required
Value type: <string>
Definition: must be set to
"arm,cci-400-ctrl-if"
- interface-type:
Usage: required
Value type: <string>
Definition: must be set to one of {"ace", "ace-lite"}
depending on the interface type the node
represents.
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- CCI PMU node
Parent node must be CCI interconnect node.
A CCI pmu node must contain the following properties:
- compatible
Usage: required
Value type: <string>
Definition: Must contain one of:
"arm,cci-400-pmu,r0"
"arm,cci-400-pmu,r1"
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
secure access to CCI registers
"arm,cci-500-pmu,r0"
"arm,cci-550-pmu,r0"
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- interrupts:
Usage: required
Value type: Integer cells. Array of interrupt specifier
entries, as defined in
../interrupt-controller/interrupts.txt.
Definition: list of counter overflow interrupts, one per
counter. The interrupts must be specified
starting with the cycle counter overflow
interrupt, followed by counter0 overflow
interrupt, counter1 overflow interrupt,...
,counterN overflow interrupt.
The CCI PMU has an interrupt signal for each
counter. The number of interrupts must be
equal to the number of counters.
* CCI interconnect bus masters
Description: masters in the device tree connected to a CCI port
(inclusive of CPUs and their cpu nodes).
A CCI interconnect bus master node must contain the following
properties:
- cci-control-port:
Usage: required
Value type: <phandle>
Definition: a phandle containing the CCI control interface node
the master is connected to.
Example:
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x1>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x100>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x101>;
};
};
dma0: dma@3000000 {
compatible = "arm,pl330", "arm,primecell";
cci-control-port = <&cci_control0>;
reg = <0x0 0x3000000 0x0 0x1000>;
interrupts = <10>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
cci@2c090000 {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x2c090000 0 0x1000>;
ranges = <0x0 0x0 0x2c090000 0x10000>;
cci_control0: slave-if@1000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace-lite";
reg = <0x1000 0x1000>;
};
cci_control1: slave-if@4000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x4000 0x1000>;
};
cci_control2: slave-if@5000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x5000 0x1000>;
};
pmu@9000 {
compatible = "arm,cci-400-pmu";
reg = <0x9000 0x5000>;
interrupts = <0 101 4>,
<0 102 4>,
<0 103 4>,
<0 104 4>,
<0 105 4>;
};
};
This CCI node corresponds to a CCI component whose control registers sits
at address 0x000000002c090000.
CCI slave interface @0x000000002c091000 is connected to dma controller dma0.
CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};
CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};

2
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -240,6 +240,8 @@ properties:
DMIPS/MHz, relative to highest capacity-dmips-mhz
in the system.
cci-control-port: true
dynamic-power-coefficient:
$ref: '/schemas/types.yaml#/definitions/uint32'
description:

20
Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
View File

@ -1,20 +0,0 @@
Trusted Foundations
-------------------
Boards that use the Trusted Foundations secure monitor can signal its
presence by declaring a node compatible with "tlm,trusted-foundations"
under the /firmware/ node
Required properties:
- compatible: "tlm,trusted-foundations"
- tlm,version-major: major version number of Trusted Foundations firmware
- tlm,version-minor: minor version number of Trusted Foundations firmware
Example:
firmware {
trusted-foundations {
compatible = "tlm,trusted-foundations";
tlm,version-major = <2>;
tlm,version-minor = <8>;
};
};

46
Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml Normal file
View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Trusted Foundations
description: |
Boards that use the Trusted Foundations secure monitor can signal its
presence by declaring a node compatible under the /firmware/ node
maintainers:
- Stephen Warren <swarren@nvidia.com>
properties:
$nodename:
const: trusted-foundations
compatible:
const: tlm,trusted-foundations
tlm,version-major:
$ref: /schemas/types.yaml#/definitions/uint32
description: major version number of Trusted Foundations firmware
tlm,version-minor:
$ref: /schemas/types.yaml#/definitions/uint32
description: minor version number of Trusted Foundations firmware
required:
- compatible
- tlm,version-major
- tlm,version-minor
additionalProperties: false
examples:
- |
firmware {
trusted-foundations {
compatible = "tlm,trusted-foundations";
tlm,version-major = <2>;
tlm,version-minor = <8>;
};
};

79
Documentation/devicetree/bindings/bus/palmbus.yaml Normal file
View File

@ -0,0 +1,79 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/palmbus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ralink PalmBus Device Tree Bindings
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
description: |
The ralink palmbus controller can be found in all ralink MIPS
SoCs. It provides an external bus for connecting multiple
external devices to the SoC.
properties:
$nodename:
pattern: "^palmbus(@[0-9a-f]+)?$"
"#address-cells":
const: 1
"#size-cells":
const: 1
compatible:
const: palmbus
reg:
maxItems: 1
ranges: true
patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
"@[0-9a-f]+$":
type: object
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
palmbus@1e000000 {
compatible = "palmbus";
reg = <0x1e000000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e000000 0x0fffff>;
gpio@600 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "mediatek,mt7621-gpio";
gpio-controller;
gpio-ranges = <&pinctrl 0 0 95>;
interrupt-controller;
reg = <0x600 0x100>;
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
};
};
...

139
Documentation/devicetree/bindings/bus/ti-sysc.txt
View File

@ -1,139 +0,0 @@
Texas Instruments sysc interconnect target module wrapper binding
Texas Instruments SoCs can have a generic interconnect target module
hardware for devices connected to various interconnects such as L3
interconnect (Arteris NoC) and L4 interconnect (Sonics s3220). The sysc
is mostly used for interaction between module and PRCM. It participates
in the OCP Disconnect Protocol but other than that is mostly independent
of the interconnect.
Each interconnect target module can have one or more devices connected to
it. There is a set of control registers for managing interconnect target
module clocks, idle modes and interconnect level resets for the module.
These control registers are sprinkled into the unused register address
space of the first child device IP block managed by the interconnect
target module and typically are named REVISION, SYSCONFIG and SYSSTATUS.
Required standard properties:
- compatible shall be one of the following generic types:
"ti,sysc"
"ti,sysc-omap2"
"ti,sysc-omap4"
"ti,sysc-omap4-simple"
or one of the following derivative types for hardware
needing special workarounds:
"ti,sysc-omap2-timer"
"ti,sysc-omap4-timer"
"ti,sysc-omap3430-sr"
"ti,sysc-omap3630-sr"
"ti,sysc-omap4-sr"
"ti,sysc-omap3-sham"
"ti,sysc-omap-aes"
"ti,sysc-mcasp"
"ti,sysc-dra7-mcasp"
"ti,sysc-usb-host-fs"
"ti,sysc-dra7-mcan"
"ti,sysc-pruss"
- reg shall have register areas implemented for the interconnect
target module in question such as revision, sysc and syss
- reg-names shall contain the register names implemented for the
interconnect target module in question such as
"rev, "sysc", and "syss"
- ranges shall contain the interconnect target module IO range
available for one or more child device IP blocks managed
by the interconnect target module, the ranges may include
multiple ranges such as device L4 range for control and
parent L3 range for DMA access
Optional properties:
- ti,sysc-mask shall contain mask of supported register bits for the
SYSCONFIG register as documented in the Technical Reference
Manual (TRM) for the interconnect target module
- ti,sysc-midle list of master idle modes supported by the interconnect
target module as documented in the TRM for SYSCONFIG
register MIDLEMODE bits
- ti,sysc-sidle list of slave idle modes supported by the interconnect
target module as documented in the TRM for SYSCONFIG
register SIDLEMODE bits
- ti,sysc-delay-us delay needed after OCP softreset before accssing
SYSCONFIG register again
- ti,syss-mask optional mask of reset done status bits as described in the
TRM for SYSSTATUS registers, typically 1 with some devices
having separate reset done bits for children like OHCI and
EHCI
- clocks clock specifier for each name in the clock-names as
specified in the binding documentation for ti-clkctrl,
typically available for all interconnect targets on TI SoCs
based on omap4 except if it's read-only register in hwauto
mode as for example omap4 L4_CFG_CLKCTRL
- clock-names should contain at least "fck", and optionally also "ick"
depending on the SoC and the interconnect target module,
some interconnect target modules also need additional
optional clocks that can be specified as listed in TRM
for the related CLKCTRL register bits 8 to 15 such as
"dbclk" or "clk32k" depending on their role
- ti,hwmods optional TI interconnect module name to use legacy
hwmod platform data
- ti,no-reset-on-init interconnect target module should not be reset at init
- ti,no-idle-on-init interconnect target module should not be idled at init
- ti,no-idle interconnect target module should not be idled
Example: Single instance of MUSB controller on omap4 using interconnect ranges
using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000):
target-module@2b000 { /* 0x4a0ab000, ap 84 12.0 */
compatible = "ti,sysc-omap2";
ti,hwmods = "usb_otg_hs";
reg = <0x2b400 0x4>,
<0x2b404 0x4>,
<0x2b408 0x4>;
reg-names = "rev", "sysc", "syss";
clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
clock-names = "fck";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x2b000 0x1000>;
usb_otg_hs: otg@0 {
compatible = "ti,omap4-musb";
reg = <0x0 0x7ff>;
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
usb-phy = <&usb2_phy>;
...
};
};
Note that other SoCs, such as am335x can have multiple child devices. On am335x
there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA
instance as children of a single interconnect target module.

216
Documentation/devicetree/bindings/bus/ti-sysc.yaml Normal file
View File

@ -0,0 +1,216 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/ti-sysc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments interconnect target module binding
maintainers:
- Tony Lindgren <tony@atomide.com>
description:
Texas Instruments SoCs can have a generic interconnect target module
for devices connected to various interconnects such as L3 interconnect
using Arteris NoC, and L4 interconnect using Sonics s3220. This module
is mostly used for interaction between module and Power, Reset and Clock
Manager PRCM. It participates in the OCP Disconnect Protocol, but other
than that it is mostly independent of the interconnect.
Each interconnect target module can have one or more devices connected to
it. There is a set of control registers for managing the interconnect target
module clocks, idle modes and interconnect level resets.
The interconnect target module control registers are sprinkled into the
unused register address space of the first child device IP block managed by
the interconnect target module. Typically the register names are REVISION,
SYSCONFIG and SYSSTATUS.
properties:
$nodename:
pattern: "^target-module(@[0-9a-f]+)?$"
compatible:
oneOf:
- items:
- enum:
- ti,sysc-omap2
- ti,sysc-omap2
- ti,sysc-omap4
- ti,sysc-omap4-simple
- ti,sysc-omap2-timer
- ti,sysc-omap4-timer
- ti,sysc-omap3430-sr
- ti,sysc-omap3630-sr
- ti,sysc-omap4-sr
- ti,sysc-omap3-sham
- ti,sysc-omap-aes
- ti,sysc-mcasp
- ti,sysc-dra7-mcasp
- ti,sysc-usb-host-fs
- ti,sysc-dra7-mcan
- ti,sysc-pruss
- const: ti,sysc
- items:
- const: ti,sysc
reg:
description:
Interconnect target module control registers consisting of
REVISION, SYSCONFIG and SYSSTATUS registers as defined in the
Technical Reference Manual for the SoC.
minItems: 1
maxItems: 3
reg-names:
description:
Interconnect target module control register names consisting
of "rev", "sysc" and "syss".
oneOf:
- minItems: 1
items:
- const: rev
- const: sysc
- const: syss
- items:
- const: rev
- const: syss
- enum: [ sysc, syss ]
power-domains:
description: Target module power domain if available.
maxItems: 1
clocks:
description:
Target module clocks consisting of one functional clock, one
interface clock, and up to 8 module specific optional clocks.
Some modules may have only the functional clock, and some have
no configurable clocks.
minItems: 1
maxItems: 4
clock-names:
description:
Target module clock names like "fck", "ick", "optck1", "optck2"
if the clocks are configurable.
oneOf:
- enum: [ ick, fck, sys_clk ]
- items:
- const: fck
- enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ]
- items:
- const: fck
- const: phy-clk
- const: phy-clk-div
- items:
- const: fck
- const: hdmi_clk
- const: sys_clk
- const: tv_clk
- items:
- const: fck
- const: ahclkx
- const: ahclkr
resets:
description:
Target module reset bit in the RSTCTRL register if wired for the module.
Note that the other reset bits should be mapped for the child device
driver to use.
maxItems: 1
reset-names:
description:
Target module reset names in the RSTCTRL register, typically named
"rstctrl" if only one reset bit is wired for the module.
items:
- const: rstctrl
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
dma-ranges: true
ti,sysc-mask:
description: Mask of supported register bits for the SYSCONFIG register
$ref: /schemas/types.yaml#/definitions/uint32
ti,sysc-midle:
description: List of hardware supported idle modes
$ref: /schemas/types.yaml#/definitions/uint32-array
ti,sysc-sidle:
description: List of hardware supported idle modes
$ref: /schemas/types.yaml#/definitions/uint32-array
ti,syss-mask:
description: Mask of supported register bits for the SYSSTATUS register
$ref: /schemas/types.yaml#/definitions/uint32
ti,sysc-delay-us:
description: Delay needed after OCP softreset before accessing SYCONFIG
default: 0
minimum: 0
maximum: 2
ti,no-reset-on-init:
description: Interconnect target module shall not be reset at init
type: boolean
ti,no-idle-on-init:
description: Interconnect target module shall not be idled at init
type: boolean
ti,no-idle:
description: Interconnect target module shall not be idled
type: boolean
ti,hwmods:
description: Interconnect module name to use with legacy hwmod data
$ref: /schemas/types.yaml#/definitions/string
deprecated: true
required:
- compatible
- '#address-cells'
- '#size-cells'
- ranges
additionalProperties:
type: object
examples:
- |
#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/clock/omap4.h>
target-module@2b000 {
compatible = "ti,sysc-omap2", "ti,sysc";
ti,hwmods = "usb_otg_hs";
reg = <0x2b400 0x4>,
<0x2b404 0x4>,
<0x2b408 0x4>;
reg-names = "rev", "sysc", "syss";
clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
clock-names = "fck";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x2b000 0x1000>;
};

2
Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
View File

@ -174,7 +174,7 @@ Example:
compatible = "rockchip,rk3399-dmc";
devfreq-events = <&dfi>;
interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_DDRCLK>;
clocks = <&cru SCLK_DDRC>;
clock-names = "dmc_clk";
operating-points-v2 = <&dmc_opp_table>;
center-supply = <&ppvar_centerlogic>;

15
Documentation/devicetree/bindings/display/msm/dp-controller.yaml
View File

@ -17,9 +17,16 @@ properties:
compatible:
enum:
- qcom,sc7180-dp
- qcom,sc8180x-dp
- qcom,sc8180x-edp
reg:
maxItems: 1
items:
- description: ahb register block
- description: aux register block
- description: link register block
- description: p0 register block
- description: p1 register block
interrupts:
maxItems: 1
@ -100,7 +107,11 @@ examples:
displayport-controller@ae90000 {
compatible = "qcom,sc7180-dp";
reg = <0xae90000 0x1400>;
reg = <0xae90000 0x200>,
<0xae90200 0x200>,
<0xae90400 0xc00>,
<0xae91000 0x400>,
<0xae91400 0x400>;
interrupt-parent = <&mdss>;
interrupts = <12>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,

232
Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml Normal file
View File

@ -0,0 +1,232 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dpu-sc7280.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DPU dt properties for SC7280
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
description: |
Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates
sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
bindings of MDSS and DPU are mentioned for SC7280.
properties:
compatible:
const: qcom,sc7280-mdss
reg:
maxItems: 1
reg-names:
const: mdss
power-domains:
maxItems: 1
clocks:
items:
- description: Display AHB clock from gcc
- description: Display AHB clock from dispcc
- description: Display core clock
clock-names:
items:
- const: iface
- const: ahb
- const: core
interrupts:
maxItems: 1
interrupt-controller: true
"#address-cells": true
"#size-cells": true
"#interrupt-cells":
const: 1
iommus:
items:
- description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
ranges: true
interconnects:
items:
- description: Interconnect path specifying the port ids for data bus
interconnect-names:
const: mdp0-mem
patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
properties:
compatible:
const: qcom,sc7280-dpu
reg:
items:
- description: Address offset and size for mdp register set
- description: Address offset and size for vbif register set
reg-names:
items:
- const: mdp
- const: vbif
clocks:
items:
- description: Display hf axi clock
- description: Display sf axi clock
- description: Display ahb clock
- description: Display lut clock
- description: Display core clock
- description: Display vsync clock
clock-names:
items:
- const: bus
- const: nrt_bus
- const: iface
- const: lut
- const: core
- const: vsync
interrupts:
maxItems: 1
power-domains:
maxItems: 1
operating-points-v2: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
Contains the list of output ports from DPU device. These ports
connect to interfaces that are external to the DPU hardware,
such as DSI, DP etc. Each output port contains an endpoint that
describes how it is connected to an external interface.
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: DPU_INTF1 (DSI)
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: DPU_INTF5 (EDP)
required:
- port@0
required:
- compatible
- reg
- reg-names
- clocks
- interrupts
- power-domains
- operating-points-v2
- ports
required:
- compatible
- reg
- reg-names
- power-domains
- clocks
- interrupts
- interrupt-controller
- iommus
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,dispcc-sc7280.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sc7280.h>
#include <dt-bindings/power/qcom-rpmpd.h>
display-subsystem@ae00000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "qcom,sc7280-mdss";
reg = <0xae00000 0x1000>;
reg-names = "mdss";
power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
clocks = <&gcc GCC_DISP_AHB_CLK>,
<&dispcc DISP_CC_MDSS_AHB_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
clock-names = "iface",
"ahb",
"core";
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <1>;
interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>;
interconnect-names = "mdp0-mem";
iommus = <&apps_smmu 0x900 0x402>;
ranges;
display-controller@ae01000 {
compatible = "qcom,sc7280-dpu";
reg = <0x0ae01000 0x8f000>,
<0x0aeb0000 0x2008>;
reg-names = "mdp", "vbif";
clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
<&gcc GCC_DISP_SF_AXI_CLK>,
<&dispcc DISP_CC_MDSS_AHB_CLK>,
<&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>,
<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
clock-names = "bus",
"nrt_bus",
"iface",
"lut",
"core",
"vsync";
interrupt-parent = <&mdss>;
interrupts = <0>;
power-domains = <&rpmhpd SC7280_CX>;
operating-points-v2 = <&mdp_opp_table>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dpu_intf1_out: endpoint {
remote-endpoint = <&dsi0_in>;
};
};
port@1 {
reg = <1>;
dpu_intf5_out: endpoint {
remote-endpoint = <&edp_in>;
};
};
};
};
};
...

1
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
View File

@ -17,6 +17,7 @@ properties:
enum:
- qcom,dsi-phy-14nm
- qcom,dsi-phy-14nm-660
- qcom,dsi-phy-14nm-8953
reg:
items:

157
Documentation/devicetree/bindings/display/msm/gpu.txt
View File

@ -1,157 +0,0 @@
Qualcomm adreno/snapdragon GPU
Required properties:
- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" or
"amd,imageon-XYZ.W", "amd,imageon"
for example: "qcom,adreno-306.0", "qcom,adreno"
Note that you need to list the less specific "qcom,adreno" (since this
is what the device is matched on), in addition to the more specific
with the chip-id.
If "amd,imageon" is used, there should be no top level msm device.
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the gpu.
- clocks: device clocks (if applicable)
See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required by a3xx, a4xx and a5xx
cores:
* "core"
* "iface"
* "mem_iface"
For GMU attached devices the GPU clocks are not used and are not required. The
following devices should not list clocks:
- qcom,adreno-630.2
- iommus: optional phandle to an adreno iommu instance
- operating-points-v2: optional phandle to the OPP operating points
- interconnects: optional phandle to an interconnect provider. See
../interconnect/interconnect.txt for details. Some A3xx and all A4xx platforms
will have two paths; all others will have one path.
- interconnect-names: The names of the interconnect paths that correspond to the
interconnects property. Values must be gfx-mem and ocmem.
- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
control the power for the GPU. Applicable targets:
- qcom,adreno-630.2
- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
points to reserved memory to store the zap shader that can be used to help
bring the GPU out of secure mode.
- firmware-name: optional property of the 'zap-shader' node, listing the
relative path of the device specific zap firmware.
- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
a4xx Snapdragon SoCs. See
Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
Optional properties:
- #cooling-cells: The value must be 2. For details, please refer
Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
Example 3xx/4xx:
/ {
...
gpu: adreno@fdb00000 {
compatible = "qcom,adreno-330.2",
"qcom,adreno";
reg = <0xfdb00000 0x10000>;
reg-names = "kgsl_3d0_reg_memory";
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "kgsl_3d0_irq";
clock-names = "core",
"iface",
"mem_iface";
clocks = <&mmcc OXILI_GFX3D_CLK>,
<&mmcc OXILICX_AHB_CLK>,
<&mmcc OXILICX_AXI_CLK>;
sram = <&gpu_sram>;
power-domains = <&mmcc OXILICX_GDSC>;
operating-points-v2 = <&gpu_opp_table>;
iommus = <&gpu_iommu 0>;
#cooling-cells = <2>;
};
gpu_sram: ocmem@fdd00000 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd00000 0x2000>,
<0xfec00000 0x180000>;
reg-names = "ctrl",
"mem";
clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
<&mmcc OCMEMCX_OCMEMNOC_CLK>;
clock-names = "core",
"iface";
#address-cells = <1>;
#size-cells = <1>;
gpu_sram: gpu-sram@0 {
reg = <0x0 0x100000>;
ranges = <0 0 0xfec00000 0x100000>;
};
};
};
Example a6xx (with GMU):
/ {
...
gpu@5000000 {
compatible = "qcom,adreno-630.2", "qcom,adreno";
#stream-id-cells = <16>;
reg = <0x5000000 0x40000>, <0x509e000 0x10>;
reg-names = "kgsl_3d0_reg_memory", "cx_mem";
#cooling-cells = <2>;
/*
* Look ma, no clocks! The GPU clocks and power are
* controlled entirely by the GMU
*/
interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&adreno_smmu 0>;
operating-points-v2 = <&gpu_opp_table>;
interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
interconnect-names = "gfx-mem";
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-430000000 {
opp-hz = /bits/ 64 <430000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
opp-peak-kBps = <5412000>;
};
opp-355000000 {
opp-hz = /bits/ 64 <355000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
opp-peak-kBps = <3072000>;
};
opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
opp-peak-kBps = <3072000>;
};
opp-180000000 {
opp-hz = /bits/ 64 <180000000>;
opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
opp-peak-kBps = <1804000>;
};
};
qcom,gmu = <&gmu>;
zap-shader {
memory-region = <&zap_shader_region>;
firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn"
};
};
};

288
Documentation/devicetree/bindings/display/msm/gpu.yaml Normal file
View File

@ -0,0 +1,288 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Devicetree bindings for the Adreno or Snapdragon GPUs
maintainers:
- Rob Clark <robdclark@gmail.com>
properties:
compatible:
oneOf:
- description: |
The driver is parsing the compat string for Adreno to
figure out the gpu-id and patch level.
items:
- pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$'
- const: qcom,adreno
- description: |
The driver is parsing the compat string for Imageon to
figure out the gpu-id and patch level.
items:
- pattern: '^amd,imageon-200\.[0-1]$'
- const: amd,imageon
clocks: true
clock-names: true
reg:
minItems: 1
maxItems: 3
reg-names:
minItems: 1
items:
- const: kgsl_3d0_reg_memory
- const: cx_mem
- const: cx_dbgc
interrupts:
maxItems: 1
interrupt-names:
maxItems: 1
interconnects:
minItems: 1
maxItems: 2
interconnect-names:
minItems: 1
items:
- const: gfx-mem
- const: ocmem
iommus:
maxItems: 1
sram:
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
maxItems: 4
description: |
phandles to one or more reserved on-chip SRAM regions.
phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
a4xx Snapdragon SoCs. See
Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
operating-points-v2: true
opp-table:
type: object
power-domains:
maxItems: 1
zap-shader:
type: object
description: |
For a5xx and a6xx devices this node contains a memory-region that
points to reserved memory to store the zap shader that can be used to
help bring the GPU out of secure mode.
properties:
memory-region:
$ref: /schemas/types.yaml#/definitions/phandle
firmware-name:
description: |
Default name of the firmware to load to the remote processor.
"#cooling-cells":
const: 2
nvmem-cell-names:
maxItems: 1
nvmem-cells:
description: efuse registers
maxItems: 1
qcom,gmu:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
For GMU attached devices a phandle to the GMU device that will
control the power for the GPU.
required:
- compatible
- reg
- interrupts
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$'
then:
properties:
clocks:
minItems: 2
maxItems: 7
clock-names:
items:
anyOf:
- const: core
description: GPU Core clock
- const: iface
description: GPU Interface clock
- const: mem
description: GPU Memory clock
- const: mem_iface
description: GPU Memory Interface clock
- const: alt_mem_iface
description: GPU Alternative Memory Interface clock
- const: gfx3d
description: GPU 3D engine clock
- const: rbbmtimer
description: GPU RBBM Timer for Adreno 5xx series
minItems: 2
maxItems: 7
required:
- clocks
- clock-names
- if:
properties:
compatible:
contains:
pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$'
then: # Since Adreno 6xx series clocks should be defined in GMU
properties:
clocks: false
clock-names: false
examples:
- |
// Example a3xx/4xx:
#include <dt-bindings/clock/qcom,mmcc-msm8974.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpu: gpu@fdb00000 {
compatible = "qcom,adreno-330.2", "qcom,adreno";
reg = <0xfdb00000 0x10000>;
reg-names = "kgsl_3d0_reg_memory";
clock-names = "core", "iface", "mem_iface";
clocks = <&mmcc OXILI_GFX3D_CLK>,
<&mmcc OXILICX_AHB_CLK>,
<&mmcc OXILICX_AXI_CLK>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "kgsl_3d0_irq";
sram = <&gpu_sram>;
power-domains = <&mmcc OXILICX_GDSC>;
operating-points-v2 = <&gpu_opp_table>;
iommus = <&gpu_iommu 0>;
#cooling-cells = <2>;
};
ocmem@fdd00000 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd00000 0x2000>,
<0xfec00000 0x180000>;
reg-names = "ctrl", "mem";
clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
<&mmcc OCMEMCX_OCMEMNOC_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0xfec00000 0x100000>;
gpu_sram: gpu-sram@0 {
reg = <0x0 0x100000>;
};
};
- |
// Example a6xx (with GMU):
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sdm845.h>
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
zap_shader_region: gpu@8f200000 {
compatible = "shared-dma-pool";
reg = <0x0 0x90b00000 0x0 0xa00000>;
no-map;
};
};
gpu@5000000 {
compatible = "qcom,adreno-630.2", "qcom,adreno";
reg = <0x5000000 0x40000>, <0x509e000 0x10>;
reg-names = "kgsl_3d0_reg_memory", "cx_mem";
#cooling-cells = <2>;
interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&adreno_smmu 0>;
operating-points-v2 = <&gpu_opp_table>;
interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
interconnect-names = "gfx-mem";
qcom,gmu = <&gmu>;
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-430000000 {
opp-hz = /bits/ 64 <430000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
opp-peak-kBps = <5412000>;
};
opp-355000000 {
opp-hz = /bits/ 64 <355000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
opp-peak-kBps = <3072000>;
};
opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
opp-peak-kBps = <3072000>;
};
opp-180000000 {
opp-hz = /bits/ 64 <180000000>;
opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
opp-peak-kBps = <1804000>;
};
};
zap-shader {
memory-region = <&zap_shader_region>;
firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn";
};
};

7
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
View File

@ -26,6 +26,10 @@ properties:
- auo,b101uan08.3
# BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel
- boe,tv105wum-nw0
# BOE TV110C9M-LL3 10.95" WUXGA TFT LCD panel
- boe,tv110c9m-ll3
# INX HJ110IZ-01A 10.95" WUXGA TFT LCD panel
- innolux,hj110iz-01a
reg:
description: the virtual channel number of a DSI peripheral
@ -36,6 +40,9 @@ properties:
pp1800-supply:
description: core voltage supply
pp3300-supply:
description: core voltage supply
avdd-supply:
description: phandle of the regulator that provides positive voltage

188
Documentation/devicetree/bindings/display/panel/panel-edp.yaml Normal file
View File

@ -0,0 +1,188 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Probeable (via DP AUX / EDID) eDP Panels with simple poweron sequences
maintainers:
- Douglas Anderson <dianders@chromium.org>
description: |
This binding file can be used to indicate that an eDP panel is connected
to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without
actually specifying exactly what panel is connected. This is useful for
the case that more than one different panel could be connected to the
board, either for second-sourcing purposes or to support multiple SKUs
with different LCDs that hook up to a common board.
As per above, a requirement for using this binding is that the panel is
represented under the DP AUX bus. This means that we can use any
information provided by the DP AUX bus (including the EDID) to identify
the panel. We can use this to identify display size, resolution, and
timings among other things.
One piece of information about eDP panels that is typically _not_
provided anywhere on the DP AUX bus is the power sequencing timings.
This is the reason why, historically, we've always had to explicitly
list eDP panels. We solve that here with two tricks. The "worst case"
power on timings for any panels expected to be connected to a board are
specified in these bindings. Once we've powered on, it's expected that
the operating system will lookup the panel in a table (based on EDID
information) to figure out other power sequencing timings.
eDP panels in general can have somewhat arbitrary power sequencing
requirements. However, even though it's arbitrary in general, the
vast majority of panel datasheets have a power sequence diagram that
looks the exactly the same as every other panel. Each panel datasheet
cares about different timings in this diagram but the fact that the
diagram is so similar means we can come up with a single driver to
handle it.
These diagrams all look roughly like this, sometimes labeled with
slightly different numbers / lines but all pretty much the same
sequence. This is because much of this diagram comes straight from
the eDP Standard.
__________________________________________________
Vdd ___/: :\____ /
_/ : : \_____/
:<T1>:<T2>: :<--T10-->:<T11>:<T12>:
: +-----------------------+---------+---------+
eDP -----------+ Black video | Src vid | Blk vid +
Display : +-----------------------+---------+---------+
: _______________________:_________:_________:
HPD :<T3>| : : |
___________| : : |_____________
: : : :
Sink +-----------------------:---------:---------+
AUX CH -----------+ AUX Ch operational : : +-------------
+-----------------------:---------:---------+
: : : :
:<T4>: :<T7>: : :
Src main +------+------+--------------+---------+
lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+-------------
+------+------+--------------+---------+
: <T5> :<-T6->:<-T8->: :
:__:<T9>:
LED_EN | |
_____________________________________| |____________________________
: :
__________:__:_
PWM | : : |
__________________________| : : |__________________________
: : : :
_____________:__________:__:_:______
Bklight ____/: : : : : :\____
power _______/ :<---T13---->: : : :<T16>: \______________
(Vbl) :<T17>:<---------T14--------->: :<-T15->:<T18>:
The above looks fairly complex but, as per above, each panel only cares
about a subset of those timings.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: edp-panel
hpd-reliable-delay-ms:
description:
A fixed amount of time that must be waited after powering on the
panel's power-supply before the HPD signal is a reliable way to know
when the AUX channel is ready. This is useful for panels that glitch
the HPD at the start of power-on. This value is not needed if HPD is
always reliable for all panels that might be connected.
hpd-absent-delay-ms:
description:
The panel specifies that HPD will be asserted this many milliseconds
from power on (timing T3 in the diagram above). If we have no way to
measure HPD then a fixed delay of this many milliseconds can be used.
This can also be used as a timeout when waiting for HPD. Does not
include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms
and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and
then we know HPD would assert in the next 120 ms. This value is not
needed if HPD hooked up, either through a GPIO in the panel node or
hooked up directly to the eDP controller.
backlight: true
enable-gpios: true
port: true
power-supply: true
no-hpd: true
hpd-gpios: true
additionalProperties: false
required:
- compatible
- power-supply
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
bridge@2d {
compatible = "ti,sn65dsi86";
reg = <0x2d>;
interrupt-parent = <&tlmm>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
vpll-supply = <&src_pp1800_s4a>;
vccio-supply = <&src_pp1800_s4a>;
vcca-supply = <&src_pp1200_l2a>;
vcc-supply = <&src_pp1200_l2a>;
clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
clock-names = "refclk";
no-hpd;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
endpoint {
remote-endpoint = <&dsi0_out>;
};
};
port@1 {
reg = <1>;
sn65dsi86_out: endpoint {
remote-endpoint = <&panel_in_edp>;
};
};
};
aux-bus {
panel {
compatible = "edp-panel";
power-supply = <&pp3300_dx_edp>;
backlight = <&backlight>;
hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
hpd-reliable-delay-ms = <15>;
port {
panel_in_edp: endpoint {
remote-endpoint = <&sn65dsi86_out>;
};
};
};
};
};
};

98
Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml Normal file
View File

@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/samsung,s6d27a1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S6D27A1 display panel
description: The S6D27A1 is a 480x800 DPI display panel from Samsung Mobile
Displays (SMD). The panel must obey the rules for a SPI slave device
as specified in spi/spi-controller.yaml
maintainers:
- Markuss Broks <markuss.broks@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: samsung,s6d27a1
reg: true
interrupts:
description: provides an optional ESD (electrostatic discharge)
interrupt that signals abnormalities in the display hardware.
This can also be raised for other reasons like erroneous
configuration.
maxItems: 1
reset-gpios: true
vci-supply:
description: regulator that supplies the VCI analog voltage
usually around 3.0 V
vccio-supply:
description: regulator that supplies the VCCIO voltage usually
around 1.8 V
backlight: true
spi-cpha: true
spi-cpol: true
spi-max-frequency:
maximum: 1200000
port: true
required:
- compatible
- reg
- vci-supply
- vccio-supply
- spi-cpha
- spi-cpol
- port
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
compatible = "spi-gpio";
sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "samsung,s6d27a1";
spi-max-frequency = <1200000>;
spi-cpha;
spi-cpol;
reg = <0>;
vci-supply = <&lcd_3v0_reg>;
vccio-supply = <&lcd_1v8_reg>;
reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio>;
interrupts = <5 IRQ_TYPE_EDGE_RISING>;
port {
panel_in: endpoint {
remote-endpoint = <&display_out>;
};
};
};
};
...

51
Documentation/devicetree/bindings/display/renesas,du.yaml
View File

@ -39,6 +39,7 @@ properties:
- renesas,du-r8a77980 # for R-Car V3H compatible DU
- renesas,du-r8a77990 # for R-Car E3 compatible DU
- renesas,du-r8a77995 # for R-Car D3 compatible DU
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
reg:
maxItems: 1
@ -773,6 +774,56 @@ allOf:
- reset-names
- renesas,vsps
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a779a0
then:
properties:
clocks:
items:
- description: Functional clock
clock-names:
maxItems: 1
items:
- const: du.0
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DSI 0
port@1:
description: DSI 1
port@2: false
port@3: false
required:
- port@0
- port@1
renesas,vsps:
minItems: 2
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
additionalProperties: false
examples:

4
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
View File

@ -60,7 +60,7 @@ Example:
blue-and-red-wiring = "crossed";
port {
lcdc_0: endpoint@0 {
lcdc_0: endpoint {
remote-endpoint = <&hdmi_0>;
};
};
@ -75,7 +75,7 @@ Example:
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
port {
hdmi_0: endpoint@0 {
hdmi_0: endpoint {
remote-endpoint = <&lcdc_0>;
};
};

4
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
View File

@ -160,8 +160,8 @@ examples:
<&xlnx_dpdma 2>,
<&xlnx_dpdma 3>;
phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>,
<&psgtr 0 PHY_TYPE_DP 1 3 27000000>;
phys = <&psgtr 1 PHY_TYPE_DP 0 3>,
<&psgtr 0 PHY_TYPE_DP 1 3>;
phy-names = "dp-phy0", "dp-phy1";
};

301
Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml Normal file
View File

@ -0,0 +1,301 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 Bootlin
%YAML 1.2
---
$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Xylon LogiCVC display controller
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
description: |
The Xylon LogiCVC is a display controller that supports multiple layers.
It is usually implemented as programmable logic and was optimized for use
with Xilinx Zynq-7000 SoCs and Xilinx FPGAs.
Because the controller is intended for use in a FPGA, most of the
configuration of the controller takes place at logic configuration bitstream
synthesis time. As a result, many of the device-tree bindings are meant to
reflect the synthesis configuration and must not be configured differently.
Matching synthesis parameters are provided when applicable.
Layers are declared in the "layers" sub-node and have dedicated configuration.
In version 3 of the controller, each layer has fixed memory offset and address
starting from the video memory base address for its framebuffer. In version 4,
framebuffers are configured with a direct memory address instead.
properties:
compatible:
enum:
- xylon,logicvc-3.02.a-display
- xylon,logicvc-4.01.a-display
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 4
clock-names:
minItems: 1
items:
# vclk is required and must be provided as first item.
- const: vclk
# Other clocks are optional and can be provided in any order.
- enum:
- vclk2
- lvdsclk
- lvdsclkn
- enum:
- vclk2
- lvdsclk
- lvdsclkn
- enum:
- vclk2
- lvdsclk
- lvdsclkn
interrupts:
maxItems: 1
memory-region:
maxItems: 1
xylon,display-interface:
enum:
# Parallel RGB interface (C_DISPLAY_INTERFACE == 0)
- parallel-rgb
# ITU-T BR656 interface (C_DISPLAY_INTERFACE == 1)
- bt656
# 4-bit LVDS interface (C_DISPLAY_INTERFACE == 2)
- lvds-4bits
# 3-bit LVDS interface (C_DISPLAY_INTERFACE == 4)
- lvds-3bits
# DVI interface (C_DISPLAY_INTERFACE == 5)
- dvi
description: Display output interface (C_DISPLAY_INTERFACE).
xylon,display-colorspace:
enum:
# RGB colorspace (C_DISPLAY_COLOR_SPACE == 0)
- rgb
# YUV 4:2:2 colorspace (C_DISPLAY_COLOR_SPACE == 1)
- yuv422
# YUV 4:4:4 colorspace (C_DISPLAY_COLOR_SPACE == 2)
- yuv444
description: Display output colorspace (C_DISPLAY_COLOR_SPACE).
xylon,display-depth:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: Display output depth (C_PIXEL_DATA_WIDTH).
xylon,row-stride:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE).
xylon,dithering:
$ref: "/schemas/types.yaml#/definitions/flag"
description: Dithering module is enabled (C_XCOLOR)
xylon,background-layer:
$ref: "/schemas/types.yaml#/definitions/flag"
description: |
The last layer is used to display a black background (C_USE_BACKGROUND).
The layer must still be registered.
xylon,layers-configurable:
$ref: "/schemas/types.yaml#/definitions/flag"
description: |
Configuration of layers' size, position and offset is enabled
(C_USE_SIZE_POSITION).
layers:
type: object
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^layer@[0-9]+$":
type: object
properties:
reg:
maxItems: 1
xylon,layer-depth:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: Layer depth (C_LAYER_X_DATA_WIDTH).
xylon,layer-colorspace:
enum:
# RGB colorspace (C_LAYER_X_TYPE == 0)
- rgb
# YUV packed colorspace (C_LAYER_X_TYPE == 0)
- yuv
description: Layer colorspace (C_LAYER_X_TYPE).
xylon,layer-alpha-mode:
enum:
# Alpha is configured layer-wide (C_LAYER_X_ALPHA_MODE == 0)
- layer
# Alpha is configured per-pixel (C_LAYER_X_ALPHA_MODE == 1)
- pixel
description: Alpha mode for the layer (C_LAYER_X_ALPHA_MODE).
xylon,layer-base-offset:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: |
Offset in number of lines (C_LAYER_X_OFFSET) starting from the
video RAM base (C_VMEM_BASEADDR), only for version 3.
xylon,layer-buffer-offset:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: |
Offset in number of lines (C_BUFFER_*_OFFSET) starting from the
layer base offset for the second buffer used in double-buffering.
xylon,layer-primary:
$ref: "/schemas/types.yaml#/definitions/flag"
description: |
Layer should be registered as a primary plane (exactly one is
required).
additionalProperties: false
required:
- reg
- xylon,layer-depth
- xylon,layer-colorspace
- xylon,layer-alpha-mode
required:
- "#address-cells"
- "#size-cells"
- layer@0
additionalProperties: false
description: |
The description of the display controller layers, containing layer
sub-nodes that each describe a registered layer.
port:
$ref: /schemas/graph.yaml#/properties/port
description: |
Video output port, typically connected to a panel or bridge.
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- interrupts
- xylon,display-interface
- xylon,display-colorspace
- xylon,display-depth
- xylon,row-stride
- layers
- port
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
logicvc: logicvc@43c00000 {
compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd";
reg = <0x43c00000 0x6000>;
#address-cells = <1>;
#size-cells = <1>;
logicvc_display: display@0 {
compatible = "xylon,logicvc-3.02.a-display";
reg = <0x0 0x6000>;
memory-region = <&logicvc_cma>;
clocks = <&logicvc_vclk 0>, <&logicvc_lvdsclk 0>;
clock-names = "vclk", "lvdsclk";
interrupt-parent = <&intc>;
interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
xylon,display-interface = "lvds-4bits";
xylon,display-colorspace = "rgb";
xylon,display-depth = <16>;
xylon,row-stride = <1024>;
xylon,layers-configurable;
layers {
#address-cells = <1>;
#size-cells = <0>;
layer@0 {
reg = <0>;
xylon,layer-depth = <16>;
xylon,layer-colorspace = "rgb";
xylon,layer-alpha-mode = "layer";
xylon,layer-base-offset = <0>;
xylon,layer-buffer-offset = <480>;
xylon,layer-primary;
};
layer@1 {
reg = <1>;
xylon,layer-depth = <16>;
xylon,layer-colorspace = "rgb";
xylon,layer-alpha-mode = "layer";
xylon,layer-base-offset = <2400>;
xylon,layer-buffer-offset = <480>;
};
layer@2 {
reg = <2>;
xylon,layer-depth = <16>;
xylon,layer-colorspace = "rgb";
xylon,layer-alpha-mode = "layer";
xylon,layer-base-offset = <960>;
xylon,layer-buffer-offset = <480>;
};
layer@3 {
reg = <3>;
xylon,layer-depth = <16>;
xylon,layer-colorspace = "rgb";
xylon,layer-alpha-mode = "layer";
xylon,layer-base-offset = <480>;
xylon,layer-buffer-offset = <480>;
};
layer@4 {
reg = <4>;
xylon,layer-depth = <16>;
xylon,layer-colorspace = "rgb";
xylon,layer-alpha-mode = "layer";
xylon,layer-base-offset = <8192>;
xylon,layer-buffer-offset = <480>;
};
};
port {
#address-cells = <1>;
#size-cells = <0>;
logicvc_output: endpoint@0 {
reg = <0>;
remote-endpoint = <&panel_input>;
};
};
};
};

14
Documentation/devicetree/bindings/example-schema.yaml
View File

@ -119,7 +119,7 @@ properties:
# valid for this binding.
clock-frequency:
# The type is set in the core schema. Per device schema only need to set
# The type is set in the core schema. Per-device schema only need to set
# constraints on the possible values.
minimum: 100
maximum: 400000
@ -133,24 +133,24 @@ properties:
# *-supply is always a single phandle, so nothing more to define.
foo-supply: true
# Vendor specific properties
# Vendor-specific properties
#
# Vendor specific properties have slightly different schema requirements than
# Vendor-specific properties have slightly different schema requirements than
# common properties. They must have at least a type definition and
# 'description'.
vendor,int-property:
description: Vendor specific properties must have a description
description: Vendor-specific properties must have a description
$ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4, 6, 8, 10]
vendor,bool-property:
description: Vendor specific properties must have a description. Boolean
description: Vendor-specific properties must have a description. Boolean
properties are one case where the json-schema 'type' keyword can be used
directly.
type: boolean
vendor,string-array-property:
description: Vendor specific properties should reference a type in the
description: Vendor-specific properties should reference a type in the
core schema.
$ref: /schemas/types.yaml#/definitions/string-array
items:
@ -158,7 +158,7 @@ properties:
- enum: [baz, boo]
vendor,property-in-standard-units-microvolt:
description: Vendor specific properties having a standard unit suffix
description: Vendor-specific properties having a standard unit suffix
don't need a type.
enum: [ 100, 200, 300 ]

62
Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml Normal file
View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: U-blox GNSS Receiver Device Tree Bindings
maintainers:
- Johan Hovold <johan@kernel.org>
description: >
The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
properties:
compatible:
enum:
- u-blox,neo-6m
- u-blox,neo-8
- u-blox,neo-m8
reg:
description: >
The DDC Slave Address, SPI chip select address, the number of the USB hub
port or the USB host-controller port to which this device is attached,
depending on the bus used. Required for the DDC, SPI or USB busses.
vcc-supply:
description: >
Main voltage regulator
timepulse-gpios:
maxItems: 1
description: >
Time pulse GPIO
u-blox,extint-gpios:
maxItems: 1
description: >
GPIO connected to the "external interrupt" input pin
v-bckp-supply:
description: >
Backup voltage regulator
current-speed: true
required:
- compatible
- vcc-supply
additionalProperties: false
examples:
- |
serial {
gnss {
compatible = "u-blox,neo-8";
v-bckp-supply = <&gnss_v_bckp_reg>;
vcc-supply = <&gnss_vcc_reg>;
};
};

45
Documentation/devicetree/bindings/gnss/u-blox.txt
View File

@ -1,45 +0,0 @@
u-blox GNSS Receiver DT binding
The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
properties.
Required properties:
- compatible : Must be one of
"u-blox,neo-6m"
"u-blox,neo-8"
"u-blox,neo-m8"
- vcc-supply : Main voltage regulator
Required properties (DDC):
- reg : DDC (I2C) slave address
Required properties (SPI):
- reg : SPI chip select address
Required properties (USB):
- reg : Number of the USB hub port or the USB host-controller port
to which this device is attached
Optional properties:
- timepulse-gpios : Time pulse GPIO
- u-blox,extint-gpios : GPIO connected to the "external interrupt" input pin
- v-bckp-supply : Backup voltage regulator
Example:
serial@1234 {
compatible = "ns16550a";
gnss {
compatible = "u-blox,neo-8";
v-bckp-supply = <&gnss_v_bckp_reg>;
vcc-supply = <&gnss_vcc_reg>;
};
};

78
Documentation/devicetree/bindings/input/cap11xx.txt
View File

@ -1,78 +0,0 @@
Device tree bindings for Microchip CAP11xx based capacitive touch sensors
The node for this device must be a child of a I2C controller node, as the
device communication via I2C only.
Required properties:
compatible: Must contain one of:
"microchip,cap1106"
"microchip,cap1126"
"microchip,cap1188"
reg: The I2C slave address of the device.
interrupts: Property describing the interrupt line the
device's ALERT#/CM_IRQ# pin is connected to.
The device only has one interrupt source.
Optional properties:
autorepeat: Enables the Linux input system's autorepeat
feature on the input device.
microchip,sensor-gain: Defines the gain of the sensor circuitry. This
effectively controls the sensitivity, as a
smaller delta capacitance is required to
generate the same delta count values.
Valid values are 1, 2, 4, and 8.
By default, a gain of 1 is set.
microchip,irq-active-high: By default the interrupt pin is active low
open drain. This property allows using the active
high push-pull output.
linux,keycodes: Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as
defaults. The array must have exactly six
entries.
Example:
i2c_controller {
cap1106@28 {
compatible = "microchip,cap1106";
interrupt-parent = <&gpio1>;
interrupts = <0 0>;
reg = <0x28>;
autorepeat;
microchip,sensor-gain = <2>;
linux,keycodes = <103>, /* KEY_UP */
<106>, /* KEY_RIGHT */
<108>, /* KEY_DOWN */
<105>, /* KEY_LEFT */
<109>, /* KEY_PAGEDOWN */
<104>; /* KEY_PAGEUP */
#address-cells = <1>;
#size-cells = <0>;
usr@0 {
label = "cap11xx:green:usr0";
reg = <0>;
};
usr@1 {
label = "cap11xx:green:usr1";
reg = <1>;
};
alive@2 {
label = "cap11xx:green:alive";
reg = <2>;
linux,default_trigger = "heartbeat";
};
};
}

81
Documentation/devicetree/bindings/input/elan,ekth3000.yaml Normal file
View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/elan,ekth3000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Elantech I2C Touchpad
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
allOf:
- $ref: touchscreen/touchscreen.yaml#
properties:
compatible:
const: elan,ekth3000
reg:
maxItems: 1
interrupts:
maxItems: 1
wakeup-source:
type: boolean
description: touchpad can be used as a wakeup source
vcc-supply:
description: a phandle for the regulator supplying 3.3V power
elan,trackpoint:
type: boolean
description: touchpad can support a trackpoint
elan,clickpad:
type: boolean
description: touchpad is a clickpad (the entire surface is a button)
elan,middle-button:
type: boolean
description: touchpad has a physical middle button
elan,x_traces:
$ref: /schemas/types.yaml#/definitions/uint32
description: number of antennas on the x axis
elan,y_traces:
$ref: /schemas/types.yaml#/definitions/uint32
description: number of antennas on the y axis
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-x-mm: true
touchscreen-y-mm: true
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchpad@15 {
compatible = "elan,ekth3000";
reg = <0x15>;
interrupt-parent = <&gpio4>;
interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>;
wakeup-source;
};
};

44
Documentation/devicetree/bindings/input/elan_i2c.txt
View File

@ -1,44 +0,0 @@
Elantech I2C Touchpad
Required properties:
- compatible: must be "elan,ekth3000".
- reg: I2C address of the chip.
- interrupts: interrupt to which the chip is connected (see interrupt
binding[0]).
Optional properties:
- wakeup-source: touchpad can be used as a wakeup source.
- pinctrl-names: should be "default" (see pinctrl binding [1]).
- pinctrl-0: a phandle pointing to the pin settings for the device (see
pinctrl binding [1]).
- vcc-supply: a phandle for the regulator supplying 3.3V power.
- elan,trackpoint: touchpad can support a trackpoint (boolean)
- elan,clickpad: touchpad is a clickpad (the entire surface is a button)
- elan,middle-button: touchpad has a physical middle button
- elan,x_traces: number of antennas on the x axis
- elan,y_traces: number of antennas on the y axis
- some generic touchscreen properties [2]:
* touchscreen-size-x
* touchscreen-size-y
* touchscreen-x-mm
* touchscreen-y-mm
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Example:
&i2c1 {
/* ... */
touchpad@15 {
compatible = "elan,ekth3000";
reg = <0x15>;
interrupt-parent = <&gpio4>;
interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>;
wakeup-source;
};
/* ... */
};

148
Documentation/devicetree/bindings/input/microchip,cap11xx.yaml Normal file
View File

@ -0,0 +1,148 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/input/microchip,cap11xx.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Device tree bindings for Microchip CAP11xx based capacitive touch sensors
description: |
The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
touch controllers and LED drivers. The device communication via I2C only.
maintainers:
- Rob Herring <robh@kernel.org>
properties:
compatible:
enum:
- microchip,cap1106
- microchip,cap1126
- microchip,cap1188
reg:
maxItems: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
interrupts:
maxItems: 1
description: |
Property describing the interrupt line the
device's ALERT#/CM_IRQ# pin is connected to.
The device only has one interrupt source.
autorepeat:
description: |
Enables the Linux input system's autorepeat feature on the input device.
linux,keycodes:
minItems: 6
maxItems: 6
description: |
Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as defaults.
The array must have exactly six entries.
microchip,sensor-gain:
$ref: /schemas/types.yaml#/definitions/uint32
default: 1
enum: [1, 2, 4, 8]
description: |
Defines the gain of the sensor circuitry. This
effectively controls the sensitivity, as a
smaller delta capacitance is required to
generate the same delta count values.
microchip,irq-active-high:
type: boolean
description: |
By default the interrupt pin is active low
open drain. This property allows using the active
high push-pull output.
patternProperties:
"^led@[0-7]$":
type: object
description: CAP11xx LEDs
$ref: /schemas/leds/common.yaml#
properties:
reg:
enum: [0, 1, 2, 3, 4, 5, 6, 7]
label: true
linux,default-trigger: true
default-state: true
required:
- reg
additionalProperties: false
allOf:
- $ref: input.yaml
- if:
properties:
compatible:
contains:
enum:
- microchip,cap1106
then:
patternProperties:
"^led@[0-7]$": false
required:
- compatible
- interrupts
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
cap1188@28 {
compatible = "microchip,cap1188";
interrupt-parent = <&gpio1>;
interrupts = <0 0>;
reg = <0x28>;
autorepeat;
microchip,sensor-gain = <2>;
linux,keycodes = <103>, /* KEY_UP */
<106>, /* KEY_RIGHT */
<108>, /* KEY_DOWN */
<105>, /* KEY_LEFT */
<109>, /* KEY_PAGEDOWN */
<104>; /* KEY_PAGEUP */
#address-cells = <1>;
#size-cells = <0>;
led@0 {
label = "cap11xx:green:usr0";
reg = <0>;
};
led@1 {
label = "cap11xx:green:usr1";
reg = <1>;
};
led@2 {
label = "cap11xx:green:alive";
reg = <2>;
linux,default-trigger = "heartbeat";
};
};
};

91
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml Normal file
View File

@ -0,0 +1,91 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Silead GSL1680 Touchscreen Controller Device Tree Bindings
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- silead,gsl1680
- silead,gsl1688
- silead,gsl3670
- silead,gsl3675
- silead,gsl3692
reg:
maxItems: 1
interrupts:
maxItems: 1
power-gpios:
maxItems: 1
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
description: >
File basename for board specific firmware
silead,max-fingers:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 5
description: >
Maximum number of fingers the touchscreen can detect
silead,home-button:
type: boolean
description: >
Does the device have a capacitive home-button build into the
touchscreen?
avdd-supply:
description: >
Regulator phandle for controller AVDD
vddio-supply:
description: >
Regulator phandle for controller VDDIO
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- power-gpios
- touchscreen-size-x
- touchscreen-size-y
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@40 {
compatible = "silead,gsl1680";
reg = <0x40>;
interrupt-parent = <&pio>;
interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
touchscreen-size-x = <480>;
touchscreen-size-y = <800>;
touchscreen-inverted-x;
touchscreen-swapped-x-y;
silead,max-fingers = <5>;
};
};
...

44
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
View File

@ -1,44 +0,0 @@
* GSL 1680 touchscreen controller
Required properties:
- compatible : Must be one of the following, depending on the model:
"silead,gsl1680"
"silead,gsl1688"
"silead,gsl3670"
"silead,gsl3675"
"silead,gsl3692"
- reg : I2C slave address of the chip (0x40)
- interrupts : interrupt specification for the gsl1680 interrupt
- power-gpios : Specification for the pin connected to the gsl1680's
shutdown input. This needs to be driven high to take the
gsl1680 out of its low power state
- touchscreen-size-x : See touchscreen.txt
- touchscreen-size-y : See touchscreen.txt
Optional properties:
- firmware-name : File basename (string) for board specific firmware
- touchscreen-inverted-x : See touchscreen.txt
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
- silead,max-fingers : maximum number of fingers the touchscreen can detect
- silead,home-button : Boolean, set to true on devices which have a
capacitive home-button build into the touchscreen
- vddio-supply : regulator phandle for controller VDDIO
- avdd-supply : regulator phandle for controller AVDD
Example:
i2c@00000000 {
gsl1680: touchscreen@40 {
compatible = "silead,gsl1680";
reg = <0x40>;
interrupt-parent = <&pio>;
interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
touchscreen-size-x = <480>;
touchscreen-size-y = <800>;
touchscreen-inverted-x;
touchscreen-swapped-x-y;
silead,max-fingers = <5>;
};
};

46
Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml Normal file
View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/msi-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MSI controller
maintainers:
- Marc Zyngier <maz@kernel.org>
description: |
An MSI controller signals interrupts to a CPU when a write is made
to an MMIO address by some master. An MSI controller may feature a
number of doorbells.
properties:
"#msi-cells":
description: |
The number of cells in an msi-specifier, required if not zero.
Typically this will encode information related to sideband data,
and will not encode doorbells or payloads as these can be
configured dynamically.
The meaning of the msi-specifier is defined by the device tree
binding of the specific MSI controller.
enum: [0, 1]
msi-controller:
description:
Identifies the node as an MSI controller.
$ref: /schemas/types.yaml#/definitions/flag
msi-ranges:
description:
A list of <phandle intspec span> tuples, where "phandle" is the
parent interrupt controller, "intspec" is the starting/base
interrupt specifier and "span" is the size of the
range. Multiple ranges can be provided.
$ref: /schemas/types.yaml#/definitions/phandle-array
dependencies:
"#msi-cells": [ msi-controller ]
additionalProperties: true

94
Documentation/devicetree/bindings/leds/register-bit-led.txt
View File

@ -1,94 +0,0 @@
Device Tree Bindings for Register Bit LEDs
Register bit leds are used with syscon multifunctional devices
where single bits in a certain register can turn on/off a
single LED. The register bit LEDs appear as children to the
syscon device, with the proper compatible string. For the
syscon bindings see:
Documentation/devicetree/bindings/mfd/syscon.yaml
Each LED is represented as a sub-node of the syscon device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
Required properties:
- compatible : must be "register-bit-led"
- offset : register offset to the register controlling this LED
- mask : bit mask for the bit controlling this LED in the register
typically 0x01, 0x02, 0x04 ...
Optional properties:
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- default-state: (optional) The initial state of the LED
see Documentation/devicetree/bindings/leds/common.txt
Example:
syscon: syscon@10000000 {
compatible = "arm,realview-pb1176-syscon", "syscon";
reg = <0x10000000 0x1000>;
led@8.0 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x01>;
label = "versatile:0";
linux,default-trigger = "heartbeat";
default-state = "on";
};
led@8.1 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x02>;
label = "versatile:1";
linux,default-trigger = "mmc0";
default-state = "off";
};
led@8.2 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x04>;
label = "versatile:2";
linux,default-trigger = "cpu0";
default-state = "off";
};
led@8.3 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x08>;
label = "versatile:3";
default-state = "off";
};
led@8.4 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x10>;
label = "versatile:4";
default-state = "off";
};
led@8.5 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x20>;
label = "versatile:5";
default-state = "off";
};
led@8.6 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x40>;
label = "versatile:6";
default-state = "off";
};
led@8.7 {
compatible = "register-bit-led";
offset = <0x08>;
mask = <0x80>;
label = "versatile:7";
default-state = "off";
};
};

95
Documentation/devicetree/bindings/leds/register-bit-led.yaml Normal file
View File

@ -0,0 +1,95 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/register-bit-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Device Tree Bindings for Register Bit LEDs
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
Register bit leds are used with syscon multifunctional devices where single
bits in a certain register can turn on/off a single LED. The register bit LEDs
appear as children to the syscon device, with the proper compatible string.
For the syscon bindings see:
Documentation/devicetree/bindings/mfd/syscon.yaml
allOf:
- $ref: /schemas/leds/common.yaml#
properties:
$nodename:
description:
The unit-address is in the form of @<reg addr>,<bit offset>
pattern: '^led@[0-9a-f]+,[0-9a-f]{1,2}$'
compatible:
const: register-bit-led
reg:
description:
The register address and size
maxItems: 1
mask:
description:
bit mask for the bit controlling this LED in the register
$ref: /schemas/types.yaml#/definitions/uint32
enum:
[ 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80, 0x100, 0x200, 0x400, 0x800,
0x1000, 0x2000, 0x4000, 0x8000, 0x10000, 0x20000, 0x40000, 0x80000,
0x100000, 0x200000, 0x400000, 0x800000, 0x1000000, 0x2000000, 0x4000000,
0x8000000, 0x10000000, 0x20000000, 0x40000000, 0x80000000 ]
offset:
description:
register offset to the register controlling this LED
$ref: /schemas/types.yaml#/definitions/uint32
deprecated: true
required:
- compatible
- mask
- reg
unevaluatedProperties: false
examples:
- |
syscon@10000000 {
compatible = "arm,realview-pb1176-syscon", "syscon";
reg = <0x10000000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x10000000 0x1000>;
led@8,0 {
compatible = "register-bit-led";
reg = <0x08 0x04>;
offset = <0x08>;
mask = <0x01>;
label = "versatile:0";
linux,default-trigger = "heartbeat";
default-state = "on";
};
led@8,1 {
compatible = "register-bit-led";
reg = <0x08 0x04>;
offset = <0x08>;
mask = <0x02>;
label = "versatile:1";
default-state = "off";
};
led@8,2 {
compatible = "register-bit-led";
reg = <0x08 0x04>;
offset = <0x08>;
mask = <0x04>;
label = "versatile:2";
default-state = "off";
};
};
...

4
Documentation/devicetree/bindings/mailbox/mtk-gce.txt
View File

@ -40,8 +40,8 @@ Optional properties for a client mutex node:
defined in 'dt-bindings/gce/<chip>-gce.h'.
Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h',
'dt-binding/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'.
'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8192-gce.h',
'dt-bindings/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'.
Such as sub-system ids, thread priority, event ids.
Example:

92
Documentation/devicetree/bindings/media/i2c/ov5640.txt
View File

@ -1,92 +0,0 @@
* Omnivision OV5640 MIPI CSI-2 / parallel sensor
Required Properties:
- compatible: should be "ovti,ov5640"
- clocks: reference to the xclk input clock.
- clock-names: should be "xclk".
- DOVDD-supply: Digital I/O voltage supply, 1.8 volts
- AVDD-supply: Analog voltage supply, 2.8 volts
- DVDD-supply: Digital core voltage supply, 1.5 volts
Optional Properties:
- reset-gpios: reference to the GPIO connected to the reset pin, if any.
This is an active low signal to the OV5640.
- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
if any. This is an active high signal to the OV5640.
- rotation: as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt,
valid values are 0 (sensor mounted upright) and 180 (sensor
mounted upside down).
The device node must contain one 'port' child node for its digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
Endpoint node required properties for CSI-2 connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
Endpoint node required properties for parallel connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- bus-width: shall be set to <8> for 8 bits parallel bus
or <10> for 10 bits parallel bus
- data-shift: shall be set to <2> for 8 bits parallel bus
(lines 9:2 are used) or <0> for 10 bits parallel bus
- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
signal.
Examples:
&i2c1 {
ov5640: camera@3c {
compatible = "ovti,ov5640";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ov5640>;
reg = <0x3c>;
clocks = <&clks IMX6QDL_CLK_CKO>;
clock-names = "xclk";
DOVDD-supply = <&vgen4_reg>; /* 1.8v */
AVDD-supply = <&vgen3_reg>; /* 2.8v */
DVDD-supply = <&vgen2_reg>; /* 1.5v */
powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
rotation = <180>;
port {
/* MIPI CSI-2 bus endpoint */
ov5640_to_mipi_csi2: endpoint {
remote-endpoint = <&mipi_csi2_from_ov5640>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
&i2c1 {
ov5640: camera@3c {
compatible = "ovti,ov5640";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ov5640>;
reg = <0x3c>;
clocks = <&clk_ext_camera>;
clock-names = "xclk";
port {
/* Parallel bus endpoint */
ov5640_to_parallel: endpoint {
remote-endpoint = <&parallel_from_ov5640>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
vsync-active = <0>;
pclk-sample = <1>;
};
};
};
};

154
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml Normal file
View File

@ -0,0 +1,154 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5640.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OmniVision OV5640 Image Sensor Device Tree Bindings
maintainers:
- Steve Longerbeam <slongerbeam@gmail.com>
allOf:
- $ref: /schemas/media/video-interface-devices.yaml#
properties:
compatible:
const: ovti,ov5640
reg:
maxItems: 1
clocks:
description: XCLK Input Clock
clock-names:
const: xclk
AVDD-supply:
description: Analog voltage supply, 2.8 volts
DVDD-supply:
description: Digital core voltage supply, 1.5 volts
DOVDD-supply:
description: Digital I/O voltage supply, 1.8 volts
powerdown-gpios:
maxItems: 1
description: >
Reference to the GPIO connected to the powerdown pin, if any.
reset-gpios:
maxItems: 1
description: >
Reference to the GPIO connected to the reset pin, if any.
rotation:
enum:
- 0
- 180
port:
description: Digital Output Port
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
const: 0
data-lanes:
minItems: 1
maxItems: 2
items:
enum: [1, 2]
bus-width:
enum: [8, 10]
data-shift:
enum: [0, 2]
required:
- compatible
- reg
- clocks
- clock-names
- AVDD-supply
- DVDD-supply
- DOVDD-supply
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
camera@3c {
compatible = "ovti,ov5640";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ov5640>;
reg = <0x3c>;
clocks = <&clks IMX6QDL_CLK_CKO>;
clock-names = "xclk";
DOVDD-supply = <&vgen4_reg>; /* 1.8v */
AVDD-supply = <&vgen3_reg>; /* 2.8v */
DVDD-supply = <&vgen2_reg>; /* 1.5v */
powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
rotation = <180>;
port {
/* MIPI CSI-2 bus endpoint */
ov5640_to_mipi_csi2: endpoint {
remote-endpoint = <&mipi_csi2_from_ov5640>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
camera@3c {
compatible = "ovti,ov5640";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ov5640>;
reg = <0x3c>;
clocks = <&clk_ext_camera>;
clock-names = "xclk";
DOVDD-supply = <&vgen4_reg>; /* 1.8v */
AVDD-supply = <&vgen3_reg>; /* 2.8v */
DVDD-supply = <&vgen2_reg>; /* 1.5v */
port {
/* Parallel bus endpoint */
ov5640_to_parallel: endpoint {
remote-endpoint = <&parallel_from_ov5640>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
vsync-active = <0>;
pclk-sample = <1>;
};
};
};
};
...

4
Documentation/devicetree/bindings/media/ti,cal.yaml
View File

@ -154,7 +154,9 @@ examples:
camera-sensor@3c {
compatible = "ovti,ov5640";
reg = <0x3c>;
AVDD-supply = <&reg_2p8v>;
DOVDD-supply = <&reg_1p8v>;
DVDD-supply = <&reg_1p5v>;
clocks = <&clk_ov5640_fixed>;
clock-names = "xclk";

29
Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt
View File

@ -1,29 +0,0 @@
Freescale DDR memory controller
Properties:
- compatible : Should include "fsl,chip-memory-controller" where
chip is the processor (bsc9132, mpc8572 etc.), or
"fsl,qoriq-memory-controller".
- reg : Address and size of DDR controller registers
- interrupts : Error interrupt of DDR controller
- little-endian : Specifies little-endian access to registers
If omitted, big-endian will be used.
Example 1:
memory-controller@2000 {
compatible = "fsl,bsc9132-memory-controller";
reg = <0x2000 0x1000>;
interrupts = <16 2 1 8>;
};
Example 2:
ddr1: memory-controller@8000 {
compatible = "fsl,qoriq-memory-controller-v4.7",
"fsl,qoriq-memory-controller";
reg = <0x8000 0x1000>;
interrupts = <16 2 1 23>;
};

83
Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml Normal file
View File

@ -0,0 +1,83 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale DDR memory controller
maintainers:
- Borislav Petkov <bp@alien8.de>
- York Sun <york.sun@nxp.com>
properties:
$nodename:
pattern: "^memory-controller@[0-9a-f]+$"
compatible:
oneOf:
- items:
- enum:
- fsl,qoriq-memory-controller-v4.4
- fsl,qoriq-memory-controller-v4.5
- fsl,qoriq-memory-controller-v4.7
- fsl,qoriq-memory-controller-v5.0
- const: fsl,qoriq-memory-controller
- enum:
- fsl,bsc9132-memory-controller
- fsl,8540-memory-controller
- fsl,8541-memory-controller
- fsl,8544-memory-controller
- fsl,8548-memory-controller
- fsl,8555-memory-controller
- fsl,8568-memory-controller
- fsl,mpc8536-memory-controller
- fsl,mpc8540-memory-controller
- fsl,mpc8541-memory-controller
- fsl,mpc8544-memory-controller
- fsl,mpc8548-memory-controller
- fsl,mpc8555-memory-controller
- fsl,mpc8560-memory-controller
- fsl,mpc8568-memory-controller
- fsl,mpc8569-memory-controller
- fsl,mpc8572-memory-controller
- fsl,mpc8349-memory-controller
- fsl,p1020-memory-controller
- fsl,p1021-memory-controller
- fsl,p2020-memory-controller
- fsl,qoriq-memory-controller
interrupts:
maxItems: 1
little-endian:
description:
Specifies little-endian access to registers. If omitted, big-endian will
be used.
type: boolean
reg:
maxItems: 1
required:
- compatible
- interrupts
- reg
additionalProperties: false
examples:
- |
memory-controller@2000 {
compatible = "fsl,bsc9132-memory-controller";
reg = <0x2000 0x1000>;
interrupts = <16 2 1 8>;
};
- |
memory-controller@8000 {
compatible = "fsl,qoriq-memory-controller-v4.7",
"fsl,qoriq-memory-controller";
reg = <0x8000 0x1000>;
interrupts = <16 2 1 23>;
};

30
Documentation/devicetree/bindings/memory-controllers/mediatek,mt7621-memc.yaml Normal file
View File

@ -0,0 +1,30 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/mediatek,mt7621-memc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MT7621 SDRAM controller
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
properties:
compatible:
const: mediatek,mt7621-memc
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
memory-controller@5000 {
compatible = "mediatek,mt7621-memc";
reg = <0x5000 0x1000>;
};

157
Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
View File

@ -1,157 +0,0 @@
======================================================================
Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
======================================================================
The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
primary use case of the Aspeed LPC controller is as a slave on the bus
(typically in a Baseboard Management Controller SoC), but under certain
conditions it can also take the role of bus master.
The LPC controller is represented as a multi-function device to account for the
mix of functionality, which includes, but is not limited to:
* An IPMI Block Transfer[2] Controller
* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
physical properties of some LPC pins, configuration of serial IRQs, and
APB-to-LPC bridging amonst other functions.
* An LPC Host Interface Controller: Manages functions exposed to the host such
as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
management and bus snoop configuration.
* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
hardware management protocols for handover between the host and baseboard
management controller.
Additionally the state of the LPC controller influences the pinmux
configuration, therefore the host portion of the controller is exposed as a
syscon as a means to arbitrate access.
[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
[2] https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
[3] https://en.wikipedia.org/wiki/Super_I/O
Required properties
===================
- compatible: One of:
"aspeed,ast2400-lpc-v2", "simple-mfd", "syscon"
"aspeed,ast2500-lpc-v2", "simple-mfd", "syscon"
"aspeed,ast2600-lpc-v2", "simple-mfd", "syscon"
- reg: contains the physical address and length values of the Aspeed
LPC memory region.
- #address-cells: <1>
- #size-cells: <1>
- ranges: Maps 0 to the physical address and length of the LPC memory
region
Example:
lpc: lpc@1e789000 {
compatible = "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
lpc_snoop: lpc-snoop@0 {
compatible = "aspeed,ast2600-lpc-snoop";
reg = <0x0 0x80>;
interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
snoop-ports = <0x80>;
};
};
LPC Host Interface Controller
-------------------
The LPC Host Interface Controller manages functions exposed to the host such as
LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
management and bus snoop configuration.
Required properties:
- compatible: One of:
"aspeed,ast2400-lpc-ctrl";
"aspeed,ast2500-lpc-ctrl";
"aspeed,ast2600-lpc-ctrl";
- reg: contains offset/length values of the host interface controller
memory regions
- clocks: contains a phandle to the syscon node describing the clocks.
There should then be one cell representing the clock to use
Optional properties:
- memory-region: A phandle to a reserved_memory region to be used for the LPC
to AHB mapping
- flash: A phandle to the SPI flash controller containing the flash to
be exposed over the LPC to AHB mapping
Example:
lpc_ctrl: lpc-ctrl@80 {
compatible = "aspeed,ast2500-lpc-ctrl";
reg = <0x80 0x80>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
memory-region = <&flash_memory>;
flash = <&spi>;
};
LPC Host Controller
-------------------
The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
between the host and the baseboard management controller. The registers exist
in the "host" portion of the Aspeed LPC controller, which must be the parent of
the LPC host controller node.
Required properties:
- compatible: One of:
"aspeed,ast2400-lhc";
"aspeed,ast2500-lhc";
"aspeed,ast2600-lhc";
- reg: contains offset/length values of the LHC memory regions. In the
AST2400 and AST2500 there are two regions.
Example:
lhc: lhc@a0 {
compatible = "aspeed,ast2500-lhc";
reg = <0xa0 0x24 0xc8 0x8>;
};
LPC reset control
-----------------
The UARTs present in the ASPEED SoC can have their resets tied to the reset
state of the LPC bus. Some systems may chose to modify this configuration.
Required properties:
- compatible: One of:
"aspeed,ast2600-lpc-reset";
"aspeed,ast2500-lpc-reset";
"aspeed,ast2400-lpc-reset";
- reg: offset and length of the IP in the LHC memory region
- #reset-controller indicates the number of reset cells expected
Example:
lpc_reset: reset-controller@98 {
compatible = "aspeed,ast2500-lpc-reset";
reg = <0x98 0x4>;
#reset-cells = <1>;
};

199
Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml Normal file
View File

@ -0,0 +1,199 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# # Copyright (c) 2021 Aspeed Tehchnology Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/aspeed-lpc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aspeed Low Pin Count (LPC) Bus Controller
maintainers:
- Andrew Jeffery <andrew@aj.id.au>
- Chia-Wei Wang <chiawei_wang@aspeedtech.com>
description:
The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
primary use case of the Aspeed LPC controller is as a slave on the bus
(typically in a Baseboard Management Controller SoC), but under certain
conditions it can also take the role of bus master.
The LPC controller is represented as a multi-function device to account for the
mix of functionality, which includes, but is not limited to
* An IPMI Block Transfer[2] Controller
* An LPC Host Interface Controller manages functions exposed to the host such
as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
management and bus snoop configuration.
* A set of SuperIO[3] scratch registers enableing implementation of e.g. custom
hardware management protocols for handover between the host and baseboard
management controller.
Additionally the state of the LPC controller influences the pinmux
configuration, therefore the host portion of the controller is exposed as a
syscon as a means to arbitrate access.
properties:
compatible:
items:
- enum:
- aspeed,ast2400-lpc-v2
- aspeed,ast2500-lpc-v2
- aspeed,ast2600-lpc-v2
- const: simple-mfd
- const: syscon
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
patternProperties:
"^lpc-ctrl@[0-9a-f]+$":
type: object
additionalProperties: false
description: |
The LPC Host Interface Controller manages functions exposed to the host such as
LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART management
and bus snoop configuration.
properties:
compatible:
items:
- enum:
- aspeed,ast2400-lpc-ctrl
- aspeed,ast2500-lpc-ctrl
- aspeed,ast2600-lpc-ctrl
reg:
maxItems: 1
clocks:
maxItems: 1
memory-region:
maxItems: 1
description: handle to memory reservation for the LPC to AHB mapping region
flash:
$ref: /schemas/types.yaml#/definitions/phandle
description: The SPI flash controller containing the flash to be exposed over the LPC to AHB mapping
required:
- compatible
- clocks
"^reset-controller@[0-9a-f]+$":
type: object
additionalProperties: false
description:
The UARTs present in the ASPEED SoC can have their resets tied to the reset
state of the LPC bus. Some systems may chose to modify this configuration
properties:
compatible:
items:
- enum:
- aspeed,ast2400-lpc-reset
- aspeed,ast2500-lpc-reset
- aspeed,ast2600-lpc-reset
reg:
maxItems: 1
'#reset-cells':
const: 1
required:
- compatible
- '#reset-cells'
"^lpc-snoop@[0-9a-f]+$":
type: object
additionalProperties: false
description:
The LPC snoop interface allows the BMC to listen on and record the data
bytes written by the Host to the targeted LPC I/O pots.
properties:
compatible:
items:
- enum:
- aspeed,ast2400-lpc-snoop
- aspeed,ast2500-lpc-snoop
- aspeed,ast2600-lpc-snoop
reg:
maxItems: 1
interrupts:
maxItems: 1
snoop-ports:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: The LPC I/O ports to snoop
required:
- compatible
- interrupts
- snoop-ports
"^uart-routing@[0-9a-f]+$":
$ref: /schemas/soc/aspeed/uart-routing.yaml#
description: The UART routing control under LPC register space
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties:
type: object
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/ast2600-clock.h>
lpc: lpc@1e789000 {
compatible = "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
lpc_ctrl: lpc-ctrl@80 {
compatible = "aspeed,ast2600-lpc-ctrl";
reg = <0x80 0x80>;
clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
memory-region = <&flash_memory>;
flash = <&spi>;
};
lpc_reset: reset-controller@98 {
compatible = "aspeed,ast2600-lpc-reset";
reg = <0x98 0x4>;
#reset-cells = <1>;
};
lpc_snoop: lpc-snoop@90 {
compatible = "aspeed,ast2600-lpc-snoop";
reg = <0x90 0x8>;
interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
snoop-ports = <0x80>;
};
};

32
Documentation/devicetree/bindings/mips/ralink.txt
View File

@ -1,32 +0,0 @@
Ralink MIPS SoC device tree bindings
1. SoCs
Each device tree must specify a compatible value for the Ralink SoC
it uses in the compatible property of the root node. The compatible
value must be one of the following values:
ralink,rt2880-soc
ralink,rt3050-soc
ralink,rt3052-soc
ralink,rt3350-soc
ralink,rt3352-soc
ralink,rt3883-soc
ralink,rt5350-soc
ralink,mt7620a-soc
ralink,mt7620n-soc
ralink,mt7628a-soc
ralink,mt7688a-soc
2. Boards
GARDENA smart Gateway (MT7688)
This board is based on the MediaTek MT7688 and equipped with 128 MiB
of DDR and 8 MiB of flash (SPI NOR) and additional 128MiB SPI NAND
storage.
------------------------------
Required root node properties:
- compatible = "gardena,smart-gateway-mt7688", "ralink,mt7688a-soc",
"ralink,mt7628a-soc";

87
Documentation/devicetree/bindings/mips/ralink.yaml Normal file
View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mips/ralink.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ralink SoC based Platforms Device Tree Bindings
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
description: |
Boards with a Ralink SoC shall have the following properties.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Boards with Ralink RT2880 SoC
items:
- enum:
- ralink,rt2880-eval-board
- const: ralink,rt2880-soc
- description: Boards with Ralink RT3050 SoC
items:
- const: ralink,rt3050-soc
- description: Boards with Ralink RT3052 SoC
items:
- enum:
- ralink,rt3052-eval-board
- const: ralink,rt3052-soc
- description: Boards with Ralink RT3350 SoC
items:
- const: ralink,rt3350-soc
- description: Boards with Ralink RT3352 SoC
items:
- const: ralink,rt3352-soc
- description: Boards with Ralink RT3383 SoC
items:
- enum:
- ralink,rt3883-eval-board
- const: ralink,rt3383-soc
- description: Boards with Ralink RT5350 SoC
items:
- const: ralink,rt5350-soc
- description: Boards with Mediatek/Ralink MT7620A SoC
items:
- enum:
- ralink,mt7620a-eval-board
- const: ralink,mt7620a-soc
- description: Boards with Mediatek/Ralink MT7620N SoC
items:
- const: ralink,mt7620n-soc
- description: Boards with Mediatek/Ralink MT7628A SoC
items:
- enum:
- onion,omega2+
- vocore,vocore2
- const: ralink,mt7628a-soc
- description: Boards with Mediatek/Ralink MT7688A SoC
items:
- enum:
- gardena,smart-gateway-mt7688
- onion,omega2+
- const: ralink,mt7628a-soc
- description: Boards with Mediatek/Ralink MT7621 SoC
items:
- enum:
- gnubee,gb-pc1
- gnubee,gb-pc2
- const: mediatek,mt7621-soc
additionalProperties: true
...

4
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
View File

@ -15,7 +15,7 @@ properties:
oneOf:
- const: allwinner,sun8i-a83t-emac
- const: allwinner,sun8i-h3-emac
- const: allwinner,sun8i-r40-emac
- const: allwinner,sun8i-r40-gmac
- const: allwinner,sun8i-v3s-emac
- const: allwinner,sun50i-a64-emac
- items:
@ -93,7 +93,7 @@ allOf:
compatible:
contains:
enum:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-r40-gmac
then:
properties:

73
Documentation/devicetree/bindings/net/asix,ax88796c.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/asix,ax88796c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASIX AX88796C SPI Ethernet Adapter
maintainers:
- Łukasz Stelmach <l.stelmach@samsung.com>
description: |
ASIX AX88796C is an Ethernet controller with a built in PHY. This
describes SPI mode of the chip.
The node for this driver must be a child node of an SPI controller,
hence all mandatory properties described in
../spi/spi-controller.yaml must be specified.
allOf:
- $ref: ethernet-controller.yaml#
properties:
compatible:
const: asix,ax88796c
reg:
maxItems: 1
spi-max-frequency:
maximum: 40000000
interrupts:
maxItems: 1
reset-gpios:
description:
A GPIO line handling reset of the chip. As the line is active low,
it should be marked GPIO_ACTIVE_LOW.
maxItems: 1
local-mac-address: true
mac-address: true
required:
- compatible
- reg
- spi-max-frequency
- interrupts
- reset-gpios
additionalProperties: false
examples:
# Artik5 eval board
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
spi0 {
#address-cells = <1>;
#size-cells = <0>;
ethernet@0 {
compatible = "asix,ax88796c";
reg = <0x0>;
local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
interrupt-parent = <&gpx2>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
spi-max-frequency = <40000000>;
reset-gpios = <&gpe0 2 GPIO_ACTIVE_LOW>;
};
};

3
Documentation/devicetree/bindings/net/brcm,bcmgenet.txt
View File

@ -2,7 +2,8 @@
Required properties:
- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2",
"brcm,genet-v3", "brcm,genet-v4", "brcm,genet-v5", "brcm,bcm2711-genet-v5".
"brcm,genet-v3", "brcm,genet-v4", "brcm,genet-v5", "brcm,bcm2711-genet-v5" or
"brcm,bcm7712-genet-v5".
- reg: address and length of the register set for the device
- interrupts and/or interrupts-extended: must be two cells, the first cell
is the general purpose interrupt line, while the second cell is the

19
Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
View File

@ -50,16 +50,29 @@ properties:
by interrupts and "host-wakeup" interrupt-names
clocks:
minItems: 1
maxItems: 2
description: 1 or 2 clocks as defined in clock-names below,
in that order
clock-names:
description: Names of the 1 to 2 supplied clocks
items:
- const: txco
- const: lpo
oneOf:
- const: extclk
deprecated: true
description: Deprecated in favor of txco
- const: txco
description: >
external reference clock (not a standalone crystal)
- const: lpo
description: >
external low power 32.768 kHz clock
- items:
- const: txco
- const: lpo
vbat-supply:
description: phandle to regulator supply for VBAT

12
Documentation/devicetree/bindings/net/dsa/dsa.yaml
View File

@ -46,6 +46,9 @@ patternProperties:
type: object
description: Ethernet switch ports
allOf:
- $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#"
properties:
reg:
description: Port number
@ -73,11 +76,14 @@ patternProperties:
dsa-tag-protocol:
description:
Instead of the default, the switch will use this tag protocol if
possible. Useful when a device supports multiple protcols and
possible. Useful when a device supports multiple protocols and
the default is incompatible with the Ethernet device.
enum:
- dsa
- edsa
- ocelot
- ocelot-8021q
- seville
phy-handle: true
@ -91,6 +97,10 @@ patternProperties:
managed: true
rx-internal-delay-ps: true
tx-internal-delay-ps: true
required:
- reg

43
Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
View File

@ -74,10 +74,42 @@ properties:
- compatible
- reg
patternProperties:
"^(ethernet-)?ports$":
patternProperties:
"^(ethernet-)?port@[0-9]+$":
allOf:
- if:
properties:
phy-mode:
contains:
enum:
- rgmii
- rgmii-rxid
- rgmii-txid
- rgmii-id
then:
properties:
rx-internal-delay-ps:
$ref: "#/$defs/internal-delay-ps"
tx-internal-delay-ps:
$ref: "#/$defs/internal-delay-ps"
required:
- compatible
- reg
$defs:
internal-delay-ps:
description:
Disable tunable delay lines using 0 ps, or enable them and select
the phase between 1640 ps (73.8 degree shift at 1Gbps) and 2260 ps
(101.7 degree shift) in increments of 0.9 degrees (20 ps).
enum:
[0, 1640, 1660, 1680, 1700, 1720, 1740, 1760, 1780, 1800, 1820, 1840,
1860, 1880, 1900, 1920, 1940, 1960, 1980, 2000, 2020, 2040, 2060, 2080,
2100, 2120, 2140, 2160, 2180, 2200, 2220, 2240, 2260]
unevaluatedProperties: false
examples:
@ -97,29 +129,40 @@ examples:
port@0 {
phy-handle = <&rgmii_phy6>;
phy-mode = "rgmii-id";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
reg = <0>;
};
port@1 {
phy-handle = <&rgmii_phy3>;
phy-mode = "rgmii-id";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
reg = <1>;
};
port@2 {
phy-handle = <&rgmii_phy4>;
phy-mode = "rgmii-id";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
reg = <2>;
};
port@3 {
phy-handle = <&rgmii_phy4>;
phy-mode = "rgmii-id";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
reg = <3>;
};
port@4 {
ethernet = <&enet2>;
phy-mode = "rgmii";
rx-internal-delay-ps = <0>;
tx-internal-delay-ps = <0>;
reg = <4>;
fixed-link {

215
Documentation/devicetree/bindings/net/dsa/qca8k.txt
View File

@ -1,215 +0,0 @@
* Qualcomm Atheros QCA8xxx switch family
Required properties:
- compatible: should be one of:
"qca,qca8327"
"qca,qca8334"
"qca,qca8337"
- #size-cells: must be 0
- #address-cells: must be 1
Optional properties:
- reset-gpios: GPIO to be used to reset the whole device
Subnodes:
The integrated switch subnode should be specified according to the binding
described in dsa/dsa.txt. If the QCA8K switch is connect to a SoC's external
mdio-bus each subnode describing a port needs to have a valid phandle
referencing the internal PHY it is connected to. This is because there's no
N:N mapping of port and PHY id.
To declare the internal mdio-bus configuration, declare a mdio node in the
switch node and declare the phandle for the port referencing the internal
PHY is connected to. In this config a internal mdio-bus is registered and
the mdio MASTER is used as communication.
Don't use mixed external and internal mdio-bus configurations, as this is
not supported by the hardware.
The CPU port of this switch is always port 0.
A CPU port node has the following optional node:
- fixed-link : Fixed-link subnode describing a link to a non-MDIO
managed entity. See
Documentation/devicetree/bindings/net/fixed-link.txt
for details.
For QCA8K the 'fixed-link' sub-node supports only the following properties:
- 'speed' (integer, mandatory), to indicate the link speed. Accepted
values are 10, 100 and 1000
- 'full-duplex' (boolean, optional), to indicate that full duplex is
used. When absent, half duplex is assumed.
Examples:
for the external mdio-bus configuration:
&mdio0 {
phy_port1: phy@0 {
reg = <0>;
};
phy_port2: phy@1 {
reg = <1>;
};
phy_port3: phy@2 {
reg = <2>;
};
phy_port4: phy@3 {
reg = <3>;
};
phy_port5: phy@4 {
reg = <4>;
};
switch@10 {
compatible = "qca,qca8337";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&gmac1>;
phy-mode = "rgmii";
fixed-link {
speed = 1000;
full-duplex;
};
};
port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&phy_port1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-handle = <&phy_port2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-handle = <&phy_port3>;
};
port@4 {
reg = <4>;
label = "lan4";
phy-handle = <&phy_port4>;
};
port@5 {
reg = <5>;
label = "wan";
phy-handle = <&phy_port5>;
};
};
};
};
for the internal master mdio-bus configuration:
&mdio0 {
switch@10 {
compatible = "qca,qca8337";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&gmac1>;
phy-mode = "rgmii";
fixed-link {
speed = 1000;
full-duplex;
};
};
port@1 {
reg = <1>;
label = "lan1";
phy-mode = "internal";
phy-handle = <&phy_port1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-mode = "internal";
phy-handle = <&phy_port2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-mode = "internal";
phy-handle = <&phy_port3>;
};
port@4 {
reg = <4>;
label = "lan4";
phy-mode = "internal";
phy-handle = <&phy_port4>;
};
port@5 {
reg = <5>;
label = "wan";
phy-mode = "internal";
phy-handle = <&phy_port5>;
};
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy_port1: phy@0 {
reg = <0>;
};
phy_port2: phy@1 {
reg = <1>;
};
phy_port3: phy@2 {
reg = <2>;
};
phy_port4: phy@3 {
reg = <3>;
};
phy_port5: phy@4 {
reg = <4>;
};
};
};
};

362
Documentation/devicetree/bindings/net/dsa/qca8k.yaml Normal file
View File

@ -0,0 +1,362 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/qca8k.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Atheros QCA83xx switch family
maintainers:
- John Crispin <john@phrozen.org>
description:
If the QCA8K switch is connect to an SoC's external mdio-bus, each subnode
describing a port needs to have a valid phandle referencing the internal PHY
it is connected to. This is because there is no N:N mapping of port and PHY
ID. To declare the internal mdio-bus configuration, declare an MDIO node in
the switch node and declare the phandle for the port, referencing the internal
PHY it is connected to. In this config, an internal mdio-bus is registered and
the MDIO master is used for communication. Mixed external and internal
mdio-bus configurations are not supported by the hardware.
properties:
compatible:
oneOf:
- enum:
- qca,qca8327
- qca,qca8328
- qca,qca8334
- qca,qca8337
description: |
qca,qca8328: referenced as AR8328(N)-AK1(A/B) QFN 176 pin package
qca,qca8327: referenced as AR8327(N)-AL1A DR-QFN 148 pin package
qca,qca8334: referenced as QCA8334-AL3C QFN 88 pin package
qca,qca8337: referenced as QCA8337N-AL3(B/C) DR-QFN 148 pin package
reg:
maxItems: 1
reset-gpios:
description:
GPIO to be used to reset the whole device
maxItems: 1
qca,ignore-power-on-sel:
$ref: /schemas/types.yaml#/definitions/flag
description:
Ignore power-on pin strapping to configure LED open-drain or EEPROM
presence. This is needed for devices with incorrect configuration or when
the OEM has decided not to use pin strapping and falls back to SW regs.
qca,led-open-drain:
$ref: /schemas/types.yaml#/definitions/flag
description:
Set LEDs to open-drain mode. This requires the qca,ignore-power-on-sel to
be set, otherwise the driver will fail at probe. This is required if the
OEM does not use pin strapping to set this mode and prefers to set it
using SW regs. The pin strappings related to LED open-drain mode are
B68 on the QCA832x and B49 on the QCA833x.
mdio:
type: object
description: Qca8k switch have an internal mdio to access switch port.
If this is not present, the legacy mapping is used and the
internal mdio access is used.
With the legacy mapping the reg corresponding to the internal
mdio is the switch reg with an offset of -1.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^(ethernet-)?phy@[0-4]$":
type: object
allOf:
- $ref: "http://devicetree.org/schemas/net/mdio.yaml#"
properties:
reg:
maxItems: 1
required:
- reg
patternProperties:
"^(ethernet-)?ports$":
type: object
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^(ethernet-)?port@[0-6]$":
type: object
description: Ethernet switch ports
properties:
reg:
description: Port number
label:
description:
Describes the label associated with this port, which will become
the netdev name
$ref: /schemas/types.yaml#/definitions/string
link:
description:
Should be a list of phandles to other switch's DSA port. This
port is used as the outgoing port towards the phandle ports. The
full routing information must be given, not just the one hop
routes to neighbouring switches
$ref: /schemas/types.yaml#/definitions/phandle-array
ethernet:
description:
Should be a phandle to a valid Ethernet device node. This host
device is what the switch port is connected to
$ref: /schemas/types.yaml#/definitions/phandle
phy-handle: true
phy-mode: true
fixed-link: true
mac-address: true
sfp: true
qca,sgmii-rxclk-falling-edge:
$ref: /schemas/types.yaml#/definitions/flag
description:
Set the receive clock phase to falling edge. Mostly commonly used on
the QCA8327 with CPU port 0 set to SGMII.
qca,sgmii-txclk-falling-edge:
$ref: /schemas/types.yaml#/definitions/flag
description:
Set the transmit clock phase to falling edge.
qca,sgmii-enable-pll:
$ref: /schemas/types.yaml#/definitions/flag
description:
For SGMII CPU port, explicitly enable PLL, TX and RX chain along with
Signal Detection. On the QCA8327 this should not be enabled, otherwise
the SGMII port will not initialize. When used on the QCA8337, revision 3
or greater, a warning will be displayed. When the CPU port is set to
SGMII on the QCA8337, it is advised to set this unless a communication
issue is observed.
required:
- reg
additionalProperties: false
oneOf:
- required:
- ports
- required:
- ethernet-ports
required:
- compatible
- reg
additionalProperties: true
examples:
- |
#include <dt-bindings/gpio/gpio.h>
mdio {
#address-cells = <1>;
#size-cells = <0>;
external_phy_port1: ethernet-phy@0 {
reg = <0>;
};
external_phy_port2: ethernet-phy@1 {
reg = <1>;
};
external_phy_port3: ethernet-phy@2 {
reg = <2>;
};
external_phy_port4: ethernet-phy@3 {
reg = <3>;
};
external_phy_port5: ethernet-phy@4 {
reg = <4>;
};
switch@10 {
compatible = "qca,qca8337";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&gmac1>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&external_phy_port1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-handle = <&external_phy_port2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-handle = <&external_phy_port3>;
};
port@4 {
reg = <4>;
label = "lan4";
phy-handle = <&external_phy_port4>;
};
port@5 {
reg = <5>;
label = "wan";
phy-handle = <&external_phy_port5>;
};
};
};
};
- |
#include <dt-bindings/gpio/gpio.h>
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch@10 {
compatible = "qca,qca8337";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&gmac1>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@1 {
reg = <1>;
label = "lan1";
phy-mode = "internal";
phy-handle = <&internal_phy_port1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-mode = "internal";
phy-handle = <&internal_phy_port2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-mode = "internal";
phy-handle = <&internal_phy_port3>;
};
port@4 {
reg = <4>;
label = "lan4";
phy-mode = "internal";
phy-handle = <&internal_phy_port4>;
};
port@5 {
reg = <5>;
label = "wan";
phy-mode = "internal";
phy-handle = <&internal_phy_port5>;
};
port@6 {
reg = <0>;
label = "cpu";
ethernet = <&gmac1>;
phy-mode = "sgmii";
qca,sgmii-rxclk-falling-edge;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
internal_phy_port1: ethernet-phy@0 {
reg = <0>;
};
internal_phy_port2: ethernet-phy@1 {
reg = <1>;
};
internal_phy_port3: ethernet-phy@2 {
reg = <2>;
};
internal_phy_port4: ethernet-phy@3 {
reg = <3>;
};
internal_phy_port5: ethernet-phy@4 {
reg = <4>;
};
};
};
};

87
Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
View File

@ -9,6 +9,7 @@ SMI-based Realtek devices.
Required properties:
- compatible: must be exactly one of:
"realtek,rtl8365mb" (4+1 ports)
"realtek,rtl8366"
"realtek,rtl8366rb" (4+1 ports)
"realtek,rtl8366s" (4+1 ports)
@ -62,6 +63,8 @@ and subnodes of DSA switches.
Examples:
An example for the RTL8366RB:
switch {
compatible = "realtek,rtl8366rb";
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
@ -151,3 +154,87 @@ switch {
};
};
};
An example for the RTL8365MB-VC:
switch {
compatible = "realtek,rtl8365mb";
mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
switch_intc: interrupt-controller {
interrupt-parent = <&gpio5>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
port@0 {
reg = <0>;
label = "swp0";
phy-handle = <&ethphy0>;
};
port@1 {
reg = <1>;
label = "swp1";
phy-handle = <&ethphy1>;
};
port@2 {
reg = <2>;
label = "swp2";
phy-handle = <&ethphy2>;
};
port@3 {
reg = <3>;
label = "swp3";
phy-handle = <&ethphy3>;
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&fec1>;
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <2000>;
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
mdio {
compatible = "realtek,smi-mdio";
#address-cells = <1>;
#size-cells = <0>;
ethphy0: phy@0 {
reg = <0>;
interrupt-parent = <&switch_intc>;
interrupts = <0>;
};
ethphy1: phy@1 {
reg = <1>;
interrupt-parent = <&switch_intc>;
interrupts = <1>;
};
ethphy2: phy@2 {
reg = <2>;
interrupt-parent = <&switch_intc>;
interrupts = <2>;
};
ethphy3: phy@3 {
reg = <3>;
interrupt-parent = <&switch_intc>;
interrupts = <3>;
};
};
};

69
Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml Normal file
View File

@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/lantiq,etop-xway.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lantiq Xway ETOP Ethernet driver
maintainers:
- John Crispin <john@phrozen.org>
properties:
$nodename:
pattern: "^ethernet@[0-9a-f]+$"
compatible:
const: lantiq,etop-xway
reg:
maxItems: 1
interrupts:
items:
- description: TX interrupt
- description: RX interrupt
interrupt-names:
items:
- const: tx
- const: rx
lantiq,tx-burst-length:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
TX programmable burst length.
enum: [2, 4, 8]
lantiq,rx-burst-length:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
RX programmable burst length.
enum: [2, 4, 8]
phy-mode: true
required:
- compatible
- reg
- interrupt-parent
- interrupts
- interrupt-names
- lantiq,tx-burst-length
- lantiq,rx-burst-length
- phy-mode
additionalProperties: false
examples:
- |
ethernet@e180000 {
compatible = "lantiq,etop-xway";
reg = <0xe180000 0x40000>;
interrupt-parent = <&icu0>;
interrupts = <73>, <78>;
interrupt-names = "tx", "rx";
lantiq,tx-burst-length = <8>;
lantiq,rx-burst-length = <8>;
phy-mode = "rmii";
};

21
Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt
View File

@ -1,21 +0,0 @@
Lantiq xRX200 GSWIP PMAC Ethernet driver
==================================
Required properties:
- compatible : "lantiq,xrx200-net" for the PMAC of the embedded
: GSWIP in the xXR200
- reg : memory range of the PMAC core inside of the GSWIP core
- interrupts : TX and RX DMA interrupts. Use interrupt-names "tx" for
: the TX interrupt and "rx" for the RX interrupt.
Example:
ethernet@e10b308 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-net";
reg = <0xe10b308 0xcf8>;
interrupts = <73>, <72>;
interrupt-names = "tx", "rx";
};

59
Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml Normal file
View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/lantiq,xrx200-net.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lantiq xRX200 GSWIP PMAC Ethernet driver
maintainers:
- Hauke Mehrtens <hauke@hauke-m.de>
properties:
$nodename:
pattern: "^ethernet@[0-9a-f]+$"
compatible:
const: lantiq,xrx200-net
reg:
maxItems: 1
interrupts:
items:
- description: TX interrupt
- description: RX interrupt
interrupt-names:
items:
- const: tx
- const: rx
'#address-cells':
const: 1
'#size-cells':
const: 0
required:
- compatible
- reg
- interrupt-parent
- interrupts
- interrupt-names
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
ethernet@e10b308 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-net";
reg = <0xe10b308 0xcf8>;
interrupt-parent = <&icu0>;
interrupts = <73>, <72>;
interrupt-names = "tx", "rx";
};

4
Documentation/devicetree/bindings/net/macb.txt
View File

@ -30,6 +30,10 @@ Required properties:
Optional elements: 'tsu_clk'
- clocks: Phandles to input clocks.
Optional properties:
- mdio: node containing PHY children. If this node is not present, then PHYs
will be direct children.
The MAC address will be determined using the optional properties
defined in ethernet.txt.

25
Documentation/devicetree/bindings/net/marvell-bluetooth.txt
View File

@ -1,25 +0,0 @@
Marvell Bluetooth Chips
-----------------------
This documents the binding structure and common properties for serial
attached Marvell Bluetooth devices. The following chips are included in
this binding:
* Marvell 88W8897 Bluetooth devices
Required properties:
- compatible: should be:
"mrvl,88w8897"
Optional properties:
None so far
Example:
&serial0 {
compatible = "ns16550a";
...
bluetooth {
compatible = "mrvl,88w8897";
};
};

31
Documentation/devicetree/bindings/net/marvell-bluetooth.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/net/marvell-bluetooth.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Marvell Bluetooth chips
description: |
This documents the binding structure and common properties for serial
attached Marvell Bluetooth devices.
maintainers:
- Rob Herring <robh@kernel.org>
properties:
compatible:
const: mrvl,88w8897
required:
- compatible
additionalProperties: false
examples:
- |
serial {
bluetooth {
compatible = "mrvl,88w8897";
};
};

170
Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml Normal file
View File

@ -0,0 +1,170 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/marvell,nci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell International Ltd. NCI NFC controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
enum:
- marvell,nfc-i2c
- marvell,nfc-spi
- marvell,nfc-uart
hci-muxed:
type: boolean
description: |
Specifies that the chip is muxing NCI over HCI frames
interrupts:
maxItems: 1
reg:
maxItems: 1
reset-n-io:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
maxItems: 1
description: |
Output GPIO pin used to reset the chip (active low)
i2c-int-falling:
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
trigged on falling edge.
i2c-int-rising:
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
trigged on rising edge.
break-control:
type: boolean
description: |
For UART type of connection. Specifies that the chip needs specific break
management.
flow-control:
type: boolean
description: |
For UART type of connection. Specifies that the chip is using RTS/CTS.
spi-cpha: true
spi-cpol: true
spi-max-frequency: true
required:
- compatible
allOf:
- if:
properties:
compatible:
contains:
const: marvell,nfc-i2c
then:
properties:
break-control: false
flow-control: false
spi-cpha: false
spi-cpol: false
spi-max-frequency: false
required:
- reg
- if:
properties:
compatible:
contains:
const: marvell,nfc-spi
then:
properties:
break-control: false
flow-control: false
i2c-int-falling: false
i2c-int-rising: false
required:
- reg
- if:
properties:
compatible:
contains:
const: marvell,nfc-uart
then:
properties:
i2c-int-falling: false
i2c-int-rising: false
interrupts: false
spi-cpha: false
spi-cpol: false
spi-max-frequency: false
reg: false
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@8 {
compatible = "marvell,nfc-i2c";
reg = <0x8>;
interrupt-parent = <&gpio3>;
interrupts = <21 IRQ_TYPE_EDGE_RISING>;
i2c-int-rising;
reset-n-io = <&gpio3 19 GPIO_ACTIVE_HIGH>;
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
nfc@0 {
compatible = "marvell,nfc-spi";
reg = <0>;
spi-max-frequency = <3000000>;
spi-cpha;
spi-cpol;
interrupt-parent = <&gpio1>;
interrupts = <17 IRQ_TYPE_EDGE_RISING>;
reset-n-io = <&gpio3 19 GPIO_ACTIVE_HIGH>;
};
};
- |
#include <dt-bindings/gpio/gpio.h>
uart {
nfc {
compatible = "marvell,nfc-uart";
reset-n-io = <&gpio3 16 GPIO_ACTIVE_HIGH>;
hci-muxed;
flow-control;
};
};

84
Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt
View File

@ -1,84 +0,0 @@
* Marvell International Ltd. NCI NFC Controller
Required properties:
- compatible: Should be:
- "marvell,nfc-uart" or "mrvl,nfc-uart" for UART devices
- "marvell,nfc-i2c" for I2C devices
- "marvell,nfc-spi" for SPI devices
Optional SoC specific properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
- reset-n-io: Output GPIO pin used to reset the chip (active low).
- hci-muxed: Specifies that the chip is muxing NCI over HCI frames.
Optional UART-based chip specific properties:
- flow-control: Specifies that the chip is using RTS/CTS.
- break-control: Specifies that the chip needs specific break management.
Optional I2C-based chip specific properties:
- i2c-int-falling: Specifies that the chip read event shall be trigged on
falling edge.
- i2c-int-rising: Specifies that the chip read event shall be trigged on
rising edge.
Example (for ARM-based BeagleBoard Black with 88W8887 on UART5):
&uart5 {
nfcmrvluart: nfcmrvluart@5 {
compatible = "marvell,nfc-uart";
reset-n-io = <&gpio3 16 0>;
hci-muxed;
flow-control;
}
};
Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1):
&i2c1 {
clock-frequency = <400000>;
nfcmrvli2c0: i2c@1 {
compatible = "marvell,nfc-i2c";
reg = <0x8>;
/* I2C INT configuration */
interrupt-parent = <&gpio3>;
interrupts = <21 0>;
/* I2C INT trigger configuration */
i2c-int-rising;
/* Reset IO */
reset-n-io = <&gpio3 19 0>;
};
};
Example (for ARM-based BeagleBoard Black on SPI0):
&spi0 {
mrvlnfcspi0: spi@0 {
compatible = "marvell,nfc-spi";
reg = <0>;
/* SPI Bus configuration */
spi-max-frequency = <3000000>;
spi-cpha;
spi-cpol;
/* SPI INT configuration */
interrupt-parent = <&gpio1>;
interrupts = <17 0>;
/* Reset IO */
reset-n-io = <&gpio3 19 0>;
};
};

61
Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/nxp,nci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP Semiconductors NCI NFC controller
maintainers:
- Charles Gorand <charles.gorand@effinnov.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
oneOf:
- const: nxp,nxp-nci-i2c
- items:
- const: nxp,pn547
- const: nxp,nxp-nci-i2c
enable-gpios:
description: Output GPIO pin used for enabling/disabling the controller
firmware-gpios:
description: Output GPIO pin used to enter firmware download mode
interrupts:
maxItems: 1
reg:
maxItems: 1
required:
- compatible
- enable-gpios
- interrupts
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@29 {
compatible = "nxp,nxp-nci-i2c";
reg = <0x29>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
firmware-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
};
};

65
Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml Normal file
View File

@ -0,0 +1,65 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/nxp,pn532.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP Semiconductors PN532 NFC controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
oneOf:
- const: nxp,pn532
- description: Deprecated bindings
enum:
- nxp,pn532-i2c
- nxp,pn533-i2c
deprecated: true
interrupts:
description: Required if connected via I2C
maxItems: 1
reg:
description: Required if connected via I2C
maxItems: 1
required:
- compatible
dependencies:
interrupts: [ 'reg' ]
additionalProperties: false
examples:
# PN532 on I2C bus
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@24 {
compatible = "nxp,pn532";
reg = <0x24>;
interrupt-parent = <&gpio1>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
};
};
# PN532 connected via UART
- |
serial@49042000 {
reg = <0x49042000 0x400>;
nfc {
compatible = "nxp,pn532";
};
};

58
Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/nxp,pn544.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP Semiconductors PN544 NFC Controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
const: nxp,pn544-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
enable-gpios:
description: Output GPIO pin used for enabling/disabling the PN544
maxItems: 1
firmware-gpios:
description: Output GPIO pin used to enter firmware download mode
maxItems: 1
required:
- compatible
- reg
- interrupts
- enable-gpios
- firmware-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@28 {
compatible = "nxp,pn544-i2c";
reg = <0x28>;
interrupt-parent = <&gpio1>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
};
};

33
Documentation/devicetree/bindings/net/nfc/nxp-nci.txt
View File

@ -1,33 +0,0 @@
* NXP Semiconductors NXP NCI NFC Controllers
Required properties:
- compatible: Should be "nxp,nxp-nci-i2c".
- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupts: GPIO interrupt to which the chip is connected
- enable-gpios: Output GPIO pin used for enabling/disabling the chip
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
- firmware-gpios: Output GPIO pin used to enter firmware download mode
Example (for ARM-based BeagleBone with NPC100 NFC controller on I2C2):
&i2c2 {
npc100: npc100@29 {
compatible = "nxp,nxp-nci-i2c";
reg = <0x29>;
clock-frequency = <100000>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
firmware-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
};
};

46
Documentation/devicetree/bindings/net/nfc/pn532.txt
View File

@ -1,46 +0,0 @@
* NXP Semiconductors PN532 NFC Controller
Required properties:
- compatible: Should be
- "nxp,pn532" Place a node with this inside the devicetree node of the bus
where the NFC chip is connected to.
Currently the kernel has phy bindings for uart and i2c.
- "nxp,pn532-i2c" (DEPRECATED) only works for the i2c binding.
- "nxp,pn533-i2c" (DEPRECATED) only works for the i2c binding.
Required properties if connected on i2c:
- clock-frequency: I²C work frequency.
- reg: for the I²C bus address. This is fixed at 0x24 for the PN532.
- interrupts: GPIO interrupt to which the chip is connected
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
Example (for ARM-based BeagleBone with PN532 on I2C2):
&i2c2 {
pn532: nfc@24 {
compatible = "nxp,pn532";
reg = <0x24>;
clock-frequency = <400000>;
interrupt-parent = <&gpio1>;
interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
};
};
Example (for PN532 connected via uart):
uart4: serial@49042000 {
compatible = "ti,omap3-uart";
pn532: nfc {
compatible = "nxp,pn532";
};
};

33
Documentation/devicetree/bindings/net/nfc/pn544.txt
View File

@ -1,33 +0,0 @@
* NXP Semiconductors PN544 NFC Controller
Required properties:
- compatible: Should be "nxp,pn544-i2c".
- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupts: GPIO interrupt to which the chip is connected
- enable-gpios: Output GPIO pin used for enabling/disabling the PN544
- firmware-gpios: Output GPIO pin used to enter firmware download mode
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
Example (for ARM-based BeagleBone with PN544 on I2C2):
&i2c2 {
pn544: pn544@28 {
compatible = "nxp,pn544-i2c";
reg = <0x28>;
clock-frequency = <400000>;
interrupt-parent = <&gpio1>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
};
};

106
Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml Normal file
View File

@ -0,0 +1,106 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/st,st-nci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics ST NCI NFC controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
enum:
- st,st21nfcb-i2c
- st,st21nfcb-spi
- st,st21nfcc-i2c
reset-gpios:
description: Output GPIO pin used for resetting the controller
ese-present:
type: boolean
description: |
Specifies that an ese is physically connected to the controller
interrupts:
maxItems: 1
reg:
maxItems: 1
spi-max-frequency: true
uicc-present:
type: boolean
description: |
Specifies that the uicc swp signal can be physically connected to the
controller
required:
- compatible
- interrupts
- reg
- reset-gpios
if:
properties:
compatible:
contains:
enum:
- st,st21nfcb-i2c
- st,st21nfcc-i2c
then:
properties:
spi-max-frequency: false
else:
required:
- spi-max-frequency
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@8 {
compatible = "st,st21nfcb-i2c";
reg = <0x08>;
interrupt-parent = <&gpio5>;
interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
ese-present;
uicc-present;
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
nfc@0 {
compatible = "st,st21nfcb-spi";
reg = <0>;
spi-max-frequency = <4000000>;
interrupt-parent = <&gpio5>;
interrupts = <2 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
ese-present;
uicc-present;
};
};

64
Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml Normal file
View File

@ -0,0 +1,64 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/st,st21nfca.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics SAS ST21NFCA NFC controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
const: st,st21nfca-i2c
enable-gpios:
description: Output GPIO pin used for enabling/disabling the controller
ese-present:
type: boolean
description: |
Specifies that an ese is physically connected to the controller
interrupts:
maxItems: 1
reg:
maxItems: 1
uicc-present:
type: boolean
description: |
Specifies that the uicc swp signal can be physically connected to the
controller
required:
- compatible
- enable-gpios
- interrupts
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
nfc@1 {
compatible = "st,st21nfca-i2c";
reg = <0x1>;
interrupt-parent = <&gpio5>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
ese-present;
uicc-present;
};
};

57
Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml Normal file
View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/nfc/st,st95hf.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics ST95HF NFC controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
properties:
compatible:
const: st,st95hf
enable-gpio:
description: Output GPIO pin used for enabling/disabling the controller
interrupts:
maxItems: 1
reg:
maxItems: 1
st95hfvin-supply:
description: ST95HF transceiver's Vin regulator supply
spi-max-frequency: true
required:
- compatible
- enable-gpio
- interrupts
- reg
- spi-max-frequency
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
nfc@0{
compatible = "st,st95hf";
reg = <0>;
spi-max-frequency = <1000000>;
enable-gpio = <&pio4 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&pio0>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
};
};

38
Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt
View File

@ -1,38 +0,0 @@
* STMicroelectronics SAS. ST NCI NFC Controller
Required properties:
- compatible: Should be "st,st21nfcb-i2c" or "st,st21nfcc-i2c".
- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupts: GPIO interrupt to which the chip is connected
- reset-gpios: Output GPIO pin used to reset the ST21NFCB
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
- ese-present: Specifies that an ese is physically connected to the nfc
controller.
- uicc-present: Specifies that the uicc swp signal can be physically
connected to the nfc controller.
Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2):
&i2c2 {
st21nfcb: st21nfcb@8 {
compatible = "st,st21nfcb-i2c";
reg = <0x08>;
clock-frequency = <400000>;
interrupt-parent = <&gpio5>;
interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
ese-present;
uicc-present;
};
};

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