mirror of
https://github.com/torvalds/linux.git
synced 2026-10-16 12:50:02 +02:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.1-rc3
Cross-merge BPF and other fixes after downstream PR. Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This commit is contained in:
Alexei Starovoitov
commit
7e033543a2
10
.mailmap
10
.mailmap
|
|
@ -19,6 +19,7 @@ Abhinav Kumar <quic_abhinavk@quicinc.com> <abhinavk@codeaurora.org>
|
|||
Ahmad Masri <quic_amasri@quicinc.com> <amasri@codeaurora.org>
|
||||
Adam Oldham <oldhamca@gmail.com>
|
||||
Adam Radford <aradford@gmail.com>
|
||||
Aditya Garg <gargaditya08@proton.me> <gargaditya08@live.com>
|
||||
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
|
||||
Adrian Bunk <bunk@stusta.de>
|
||||
Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com>
|
||||
|
|
@ -207,6 +208,7 @@ Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
|
|||
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
Dan Carpenter <error27@gmail.com> <dan.carpenter@linaro.org>
|
||||
Dan Carpenter <error27@gmail.com> <dan.carpenter@oracle.com>
|
||||
Dan Williams <djbw@kernel.org> <dan.j.williams@intel.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
|
|
@ -338,6 +340,7 @@ Herbert Xu <herbert@gondor.apana.org.au>
|
|||
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
|
||||
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
|
||||
Ignat Korchagin <ignat@linux.win> <ignat@cloudflare.com>
|
||||
Igor Korotin <igor.korotin@linux.dev> <igor.korotin.linux@gmail.com>
|
||||
Ike Panhc <ikepanhc@gmail.com> <ike.pan@canonical.com>
|
||||
J. Bruce Fields <bfields@fieldses.org> <bfields@redhat.com>
|
||||
J. Bruce Fields <bfields@fieldses.org> <bfields@citi.umich.edu>
|
||||
|
|
@ -494,6 +497,7 @@ Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
|||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
|
||||
Leo Yan <leo.yan@linux.dev> <leo.yan@linaro.org>
|
||||
Liam R. Howlett <liam@infradead.org> <Liam.Howlett@oracle.com>
|
||||
Liam Mark <quic_lmark@quicinc.com> <lmark@codeaurora.org>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
|
||||
|
|
@ -504,6 +508,8 @@ Linus Walleij <linusw@kernel.org> <linus.walleij@stericsson.com>
|
|||
Linus Walleij <linusw@kernel.org> <linus.walleij@linaro.org>
|
||||
Linus Walleij <linusw@kernel.org> <triad@df.lth.se>
|
||||
<linux-hardening@vger.kernel.org> <kernel-hardening@lists.openwall.com>
|
||||
Li Wang <li.wang@linux.dev> <liwang@redhat.com>
|
||||
Li Wang <li.wang@linux.dev> <wangli.ahau@gmail.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
|
||||
|
|
@ -586,6 +592,7 @@ Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
|
|||
Michel Lespinasse <michel@lespinasse.org> <walken@zoy.org>
|
||||
Mickaël Salaün <mic@digikod.net> <mic@linux.microsoft.com>
|
||||
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
|
||||
Mike Leach <mike.leach@arm.com> <mike.leach@linaro.org>
|
||||
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
|
||||
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
|
||||
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>
|
||||
|
|
@ -675,6 +682,7 @@ Peter A Jonsson <pj@ludd.ltu.se>
|
|||
Peter Hilber <peter.hilber@oss.qualcomm.com> <quic_philber@quicinc.com>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Peter Rosin <peda@lysator.liu.se> <peda@axentia.se>
|
||||
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> <pierre-louis.bossart@linux.intel.com>
|
||||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Pratyush Yadav <pratyush@kernel.org> <ptyadav@amazon.de>
|
||||
|
|
@ -685,6 +693,7 @@ Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
|
|||
Puranjay Mohan <puranjay@kernel.org> <puranjay12@gmail.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@imgtec.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
|
||||
Qi Zheng <qi.zheng@linux.dev> <zhengqi.arch@bytedance.com>
|
||||
Quentin Monnet <qmo@kernel.org> <quentin.monnet@netronome.com>
|
||||
Quentin Monnet <qmo@kernel.org> <quentin@isovalent.com>
|
||||
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
|
||||
|
|
@ -743,6 +752,7 @@ Sarangdhar Joshi <spjoshi@codeaurora.org>
|
|||
Saravana Kannan <saravanak@kernel.org> <skannan@codeaurora.org>
|
||||
Saravana Kannan <saravanak@kernel.org> <saravanak@google.com>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
Sasha Finkelstein <k@chaosmail.tech> <fnkl.kernel@gmail.com>
|
||||
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
|
||||
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
|
||||
Satya Priya <quic_skakitap@quicinc.com> <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
|
||||
|
|
|
|||
13
CREDITS
13
CREDITS
|
|
@ -1451,6 +1451,14 @@ N: Andy Gospodarek
|
|||
E: andy@greyhouse.net
|
||||
D: Maintenance and contributions to the network interface bonding driver.
|
||||
|
||||
N: Vivek Goyal
|
||||
E: vgoyal@redhat.com
|
||||
D: KDUMP, KEXEC, and VIRTIO FILE SYSTEM
|
||||
|
||||
N: Alexander Graf
|
||||
E: graf@amazon.com
|
||||
D: Kexec Handover (KHO)
|
||||
|
||||
N: Wolfgang Grandegger
|
||||
E: wg@grandegger.com
|
||||
D: Controller Area Network (device drivers)
|
||||
|
|
@ -3644,6 +3652,11 @@ S: Dag Hammerskjolds v. 3E
|
|||
S: S-226 64 LUND
|
||||
S: Sweden
|
||||
|
||||
N: Tilman Schmidt
|
||||
E: tilman@imap.cc
|
||||
D: Siemens Gigaset ISDN driver author and maintainer
|
||||
D: ISDN CAPI subsystem contributions
|
||||
|
||||
N: Henning P. Schmiedehausen
|
||||
E: hps@tanstaafl.de
|
||||
D: added PCI support to the serial driver
|
||||
|
|
|
|||
|
|
@ -783,11 +783,9 @@ namespaces/compatibility-list admin-guide/namespaces/compatibility-list
|
|||
namespaces/index admin-guide/namespaces/index
|
||||
namespaces/resource-control admin-guide/namespaces/resource-control
|
||||
networking/altera_tse networking/device_drivers/ethernet/altera/altera_tse
|
||||
networking/baycom networking/device_drivers/hamradio/baycom
|
||||
networking/bpf_flow_dissector bpf/prog_flow_dissector
|
||||
networking/cxacru networking/device_drivers/atm/cxacru
|
||||
networking/defza networking/device_drivers/fddi/defza
|
||||
networking/device_drivers/3com/3c509 networking/device_drivers/ethernet/3com/3c509
|
||||
networking/device_drivers/3com/vortex networking/device_drivers/ethernet/3com/vortex
|
||||
networking/device_drivers/amazon/ena networking/device_drivers/ethernet/amazon/ena
|
||||
networking/device_drivers/aquantia/atlantic networking/device_drivers/ethernet/aquantia/atlantic
|
||||
|
|
@ -822,7 +820,6 @@ networking/device_drivers/microsoft/netvsc networking/device_drivers/ethernet/mi
|
|||
networking/device_drivers/netronome/nfp networking/device_drivers/ethernet/netronome/nfp
|
||||
networking/device_drivers/pensando/ionic networking/device_drivers/ethernet/pensando/ionic
|
||||
networking/device_drivers/qualcomm/rmnet networking/device_drivers/cellular/qualcomm/rmnet
|
||||
networking/device_drivers/smsc/smc9 networking/device_drivers/ethernet/smsc/smc9
|
||||
networking/device_drivers/stmicro/stmmac networking/device_drivers/ethernet/stmicro/stmmac
|
||||
networking/device_drivers/ti/cpsw networking/device_drivers/ethernet/ti/cpsw
|
||||
networking/device_drivers/ti/cpsw_switchdev networking/device_drivers/ethernet/ti/cpsw_switchdev
|
||||
|
|
@ -836,19 +833,16 @@ networking/e100 networking/device_drivers/ethernet/intel/e100
|
|||
networking/e1000 networking/device_drivers/ethernet/intel/e1000
|
||||
networking/e1000e networking/device_drivers/ethernet/intel/e1000e
|
||||
networking/fm10k networking/device_drivers/ethernet/intel/fm10k
|
||||
networking/fore200e networking/device_drivers/atm/fore200e
|
||||
networking/hinic networking/device_drivers/ethernet/huawei/hinic
|
||||
networking/i40e networking/device_drivers/ethernet/intel/i40e
|
||||
networking/iavf networking/device_drivers/ethernet/intel/iavf
|
||||
networking/ice networking/device_drivers/ethernet/intel/ice
|
||||
networking/igb networking/device_drivers/ethernet/intel/igb
|
||||
networking/igbvf networking/device_drivers/ethernet/intel/igbvf
|
||||
networking/iphase networking/device_drivers/atm/iphase
|
||||
networking/ixgbe networking/device_drivers/ethernet/intel/ixgbe
|
||||
networking/ixgbevf networking/device_drivers/ethernet/intel/ixgbevf
|
||||
networking/netdev-FAQ process/maintainer-netdev
|
||||
networking/skfp networking/device_drivers/fddi/skfp
|
||||
networking/z8530drv networking/device_drivers/hamradio/z8530drv
|
||||
nfc/index driver-api/nfc/index
|
||||
nfc/nfc-hci driver-api/nfc/nfc-hci
|
||||
nfc/nfc-pn544 driver-api/nfc/nfc-pn544
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ What: /sys/accessibility/speakup/bleeps
|
|||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls whether one hears beeps through the PC speaker
|
||||
when using speakup's review commands.
|
||||
TODO: what values does it accept?
|
||||
when using speakup's review commands. Range: 0-3. 0 = off, 1 = beeps
|
||||
only, 2 = announcements only, 3 = beeps and announcements (default).
|
||||
|
||||
What: /sys/accessibility/speakup/bleep_time
|
||||
KernelVersion: 2.6
|
||||
|
|
|
|||
|
|
@ -278,3 +278,13 @@ Date: Aug 2025
|
|||
KernelVersion 6.18
|
||||
Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
|
||||
Description: (Read) Show hardware context information of device.
|
||||
|
||||
What: /sys/bus/coresight/devices/<tpdm-name>/traceid
|
||||
Date: March 2026
|
||||
KernelVersion: 7.1
|
||||
Contact: Jie Gan <jie.gan@oss.qualcomm.com>
|
||||
Description:
|
||||
(R) Show the trace ID that will appear in the trace stream
|
||||
coming from this TPDM. The trace ID is inherited from the
|
||||
connected TPDA device and is fixed for the lifetime of the
|
||||
device. Returns -EINVAL if the device has not been enabled yet.
|
||||
|
|
|
|||
|
|
@ -172,3 +172,23 @@ Description:
|
|||
the automatic retries. Exist only when I3C constroller supports
|
||||
this retry on nack feature.
|
||||
|
||||
What: /sys/bus/i3c/devices/i3c-<bus-id>/do_daa
|
||||
KernelVersion: 7.0
|
||||
Contact: linux-i3c@vger.kernel.org
|
||||
Description:
|
||||
Write-only attribute that triggers a Dynamic Address Assignment
|
||||
(DAA) procedure which discovers new I3C devices on the bus.
|
||||
Writing a boolean true value (1, y, yes, true, on) to this
|
||||
attribute causes the master controller to perform DAA, which
|
||||
includes broadcasting an ENTDAA (Enter Dynamic Address Assignment)
|
||||
Common Command Code (CCC) on the bus. Writing a false value
|
||||
returns -EINVAL.
|
||||
|
||||
This is useful for discovering I3C devices that were not present
|
||||
during initial bus initialization and are unable to issue
|
||||
Hot-Join. Only devices without a currently assigned dynamic address
|
||||
will respond to the ENTDAA broadcast and be assigned addresses.
|
||||
|
||||
Note that this mechanism is distinct from Hot-Join, since this is
|
||||
controller-initiated discovery, while Hot-Join is device-initiated
|
||||
method to provoke controller discovery procedure.
|
||||
|
|
|
|||
|
|
@ -1428,7 +1428,7 @@ KernelVersion: 2.6.35
|
|||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The name of the trigger source being used, as per string given
|
||||
in /sys/class/iio/triggerY/name.
|
||||
in /sys/bus/iio/devices/triggerY/name.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/bufferY/length
|
||||
KernelVersion: 5.11
|
||||
|
|
|
|||
|
|
@ -675,7 +675,8 @@ Description:
|
|||
|
||||
Valid values:
|
||||
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
|
||||
"PD_DRP", "PD_PPS", "BrickID"
|
||||
"PD_DRP", "PD_PPS", "BrickID", "PD_SPR_AVS",
|
||||
"PD_PPS_SPR_AVS"
|
||||
|
||||
**Device Specific Properties**
|
||||
|
||||
|
|
|
|||
|
|
@ -1768,3 +1768,26 @@ Description:
|
|||
==================== ===========================
|
||||
|
||||
The attribute is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/dme_qos_notification
|
||||
What: /sys/bus/platform/devices/*.ufs/dme_qos_notification
|
||||
Date: March 2026
|
||||
Contact: Can Guo <can.guo@oss.qualcomm.com>
|
||||
Description:
|
||||
This attribute reports and clears pending DME (Device Management
|
||||
Entity) Quality of Service (QoS) notifications. This attribute
|
||||
is a bitfield with the following bit assignments:
|
||||
|
||||
Bit Description
|
||||
=== ======================================
|
||||
0 DME QoS Monitor has been reset by host
|
||||
1 QoS from TX is detected
|
||||
2 QoS from RX is detected
|
||||
3 QoS from PA_INIT is detected
|
||||
|
||||
Reading this attribute returns the pending DME QoS notification
|
||||
bits. Writing '0' to this attribute clears pending DME QoS
|
||||
notification bits. Writing any non-zero value is invalid and
|
||||
will be rejected.
|
||||
|
||||
The attribute is read/write.
|
||||
|
|
|
|||
|
|
@ -51,3 +51,30 @@ Description:
|
|||
|
||||
Reading this file returns the current status of the breathing animation
|
||||
functionality.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/ctgp_offset
|
||||
Date: January 2026
|
||||
KernelVersion: 7.0
|
||||
Contact: Werner Sembach <wse@tuxedocomputers.com>
|
||||
Description:
|
||||
Allows userspace applications to set the configurable TGP offset on top of the base
|
||||
TGP. Base TGP and max TGP and therefore the max cTGP offset are device specific.
|
||||
Note that setting the maximum cTGP leaves no window open for Dynamic Boost as
|
||||
Dynamic Boost also can not go over max TGP. Setting the cTGP to maximum is
|
||||
effectively disabling Dynamic Boost and telling the device to always prioritize the
|
||||
GPU over the CPU.
|
||||
|
||||
Reading this file returns the current configurable TGP offset.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/usb_c_power_priority
|
||||
Date: February 2026
|
||||
KernelVersion: 7.1
|
||||
Contact: Werner Sembach <wse@tuxedocomputers.com>
|
||||
Description:
|
||||
Allows userspace applications to choose the USB-C power distribution profile between
|
||||
one that offers a bigger share of the power to the battery and one that offers more
|
||||
of it to the CPU. Writing "charging"/"performance" into this file selects the
|
||||
respective profile.
|
||||
|
||||
Reading this file returns the profile names with the currently active one in
|
||||
brackets.
|
||||
|
|
|
|||
|
|
@ -407,6 +407,12 @@ Contact: "Hridya Valsaraju" <hridya@google.com>
|
|||
Description: Average number of valid blocks.
|
||||
Available when CONFIG_F2FS_STAT_FS=y.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/defrag_blocks
|
||||
Date: February 2026
|
||||
Contact: "Jinbao Liu" <liujinbao1@xiaomi.com>
|
||||
Description: Number of blocks moved by defragment.
|
||||
Available when CONFIG_F2FS_STAT_FS=y.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/mounted_time_sec
|
||||
Date: February 2020
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
|
|
|
|||
|
|
@ -47,21 +47,19 @@ Please note that implementation details can be changed.
|
|||
Called when swp_entry's refcnt goes down to 0. A charge against swap
|
||||
disappears.
|
||||
|
||||
3. charge-commit-cancel
|
||||
3. charge-commit
|
||||
=======================
|
||||
|
||||
Memcg pages are charged in two steps:
|
||||
|
||||
- mem_cgroup_try_charge()
|
||||
- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
|
||||
- commit_charge()
|
||||
|
||||
At try_charge(), there are no flags to say "this page is charged".
|
||||
at this point, usage += PAGE_SIZE.
|
||||
|
||||
At commit(), the page is associated with the memcg.
|
||||
|
||||
At cancel(), simply usage -= PAGE_SIZE.
|
||||
|
||||
Under below explanation, we assume CONFIG_SWAP=y.
|
||||
|
||||
4. Anonymous
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ cgroup v2 currently supports the following mount options.
|
|||
memory_hugetlb_accounting
|
||||
Count HugeTLB memory usage towards the cgroup's overall
|
||||
memory usage for the memory controller (for the purpose of
|
||||
statistics reporting and memory protetion). This is a new
|
||||
statistics reporting and memory protection). This is a new
|
||||
behavior that could regress existing setups, so it must be
|
||||
explicitly opted in with this mount option.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
APPARMOR AppArmor support is enabled.
|
||||
ARM ARM architecture is enabled.
|
||||
ARM64 ARM64 architecture is enabled.
|
||||
AX25 Appropriate AX.25 support is enabled.
|
||||
CLK Common clock infrastructure is enabled.
|
||||
CMA Contiguous Memory Area support is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
|
|
@ -633,23 +632,6 @@ Kernel parameters
|
|||
1 - Enable the BAU.
|
||||
unset - Disable the BAU.
|
||||
|
||||
baycom_epp= [HW,AX25]
|
||||
Format: <io>,<mode>
|
||||
|
||||
baycom_par= [HW,AX25] BayCom Parallel Port AX.25 Modem
|
||||
Format: <io>,<mode>
|
||||
See header of drivers/net/hamradio/baycom_par.c.
|
||||
|
||||
baycom_ser_fdx= [HW,AX25]
|
||||
BayCom Serial Port AX.25 Modem (Full Duplex Mode)
|
||||
Format: <io>,<irq>,<mode>[,<baud>]
|
||||
See header of drivers/net/hamradio/baycom_ser_fdx.c.
|
||||
|
||||
baycom_ser_hdx= [HW,AX25]
|
||||
BayCom Serial Port AX.25 Modem (Half Duplex Mode)
|
||||
Format: <io>,<irq>,<mode>
|
||||
See header of drivers/net/hamradio/baycom_ser_hdx.c.
|
||||
|
||||
bdev_allow_write_mounted=
|
||||
Format: <bool>
|
||||
Control the ability to open a mounted block device
|
||||
|
|
|
|||
|
|
@ -1522,6 +1522,27 @@ Currently 2 antenna types are supported as mentioned below:
|
|||
The property is read-only. If the platform doesn't have support the sysfs
|
||||
class is not created.
|
||||
|
||||
doubletap_enable
|
||||
----------------
|
||||
|
||||
sysfs: doubletap_enable
|
||||
|
||||
Controls whether TrackPoint doubletap events are filtered out. Doubletap is a
|
||||
feature where quickly tapping the TrackPoint twice triggers a special function key event.
|
||||
|
||||
The available commands are::
|
||||
|
||||
cat /sys/devices/platform/thinkpad_acpi/doubletap_enable
|
||||
echo 1 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
|
||||
echo 0 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
|
||||
|
||||
Values:
|
||||
|
||||
* 1 - doubletap events are processed (default)
|
||||
* 0 - doubletap events are filtered out (ignored)
|
||||
|
||||
This setting can also be toggled via the Fn+doubletap hotkey.
|
||||
|
||||
Auxmac
|
||||
------
|
||||
|
||||
|
|
|
|||
|
|
@ -50,6 +50,10 @@ between 1 and 100 percent are supported.
|
|||
Additionally the driver signals the presence of battery charging issues through the standard
|
||||
``health`` power supply sysfs attribute.
|
||||
|
||||
It also lets you set whether a USB-C power source should prioritise charging the battery or
|
||||
delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for
|
||||
details.
|
||||
|
||||
Lightbar
|
||||
--------
|
||||
|
||||
|
|
@ -58,3 +62,11 @@ LED class device. The default name of this LED class device is ``uniwill:multico
|
|||
|
||||
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
|
||||
animation modes of the lightbar.
|
||||
|
||||
Configurable TGP
|
||||
----------------
|
||||
|
||||
The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that
|
||||
allow it.
|
||||
|
||||
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
|
||||
|
|
|
|||
|
|
@ -79,6 +79,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this
|
|||
parameter is set as ``N``. If invalid parameters are found while the
|
||||
re-reading, DAMON_LRU_SORT will be disabled.
|
||||
|
||||
Once ``Y`` is written to this parameter, the user must not write to any
|
||||
parameters until reading ``commit_inputs`` again returns ``N``. If users
|
||||
violate this rule, the kernel may exhibit undefined behavior.
|
||||
|
||||
active_mem_bp
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -71,6 +71,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this
|
|||
parameter is set as ``N``. If invalid parameters are found while the
|
||||
re-reading, DAMON_RECLAIM will be disabled.
|
||||
|
||||
Once ``Y`` is written to this parameter, the user must not write to any
|
||||
parameters until reading ``commit_inputs`` again returns ``N``. If users
|
||||
violate this rule, the kernel may exhibit undefined behavior.
|
||||
|
||||
min_age
|
||||
-------
|
||||
|
||||
|
|
|
|||
|
|
@ -42,6 +42,45 @@ For example, if you used ``reserve_mem`` command line parameter to create
|
|||
an early memory reservation, the new kernel will have that memory at the
|
||||
same physical address as the old kernel.
|
||||
|
||||
Kexec Metadata
|
||||
==============
|
||||
|
||||
KHO automatically tracks metadata about the kexec chain, passing information
|
||||
about the previous kernel to the next kernel. This feature helps diagnose
|
||||
bugs that only reproduce when kexecing from specific kernel versions.
|
||||
|
||||
On each KHO kexec, the kernel logs the previous kernel's version and the
|
||||
number of kexec reboots since the last cold boot::
|
||||
|
||||
[ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (count 1)
|
||||
|
||||
The metadata includes:
|
||||
|
||||
``previous_release``
|
||||
The kernel version string (from ``uname -r``) of the kernel that
|
||||
initiated the kexec.
|
||||
|
||||
``kexec_count``
|
||||
The number of kexec boots since the last cold boot. On cold boot,
|
||||
this counter starts at 0 and increments with each kexec. This helps
|
||||
identify issues that only manifest after multiple consecutive kexec
|
||||
reboots.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
This metadata is particularly useful for debugging kexec transition bugs,
|
||||
where a buggy kernel kexecs into a new kernel and the bug manifests only
|
||||
in the second kernel. Examples of such bugs include:
|
||||
|
||||
- Memory corruption from the previous kernel affecting the new kernel
|
||||
- Incorrect hardware state left by the previous kernel
|
||||
- Firmware/ACPI state issues that only appear in kexec scenarios
|
||||
|
||||
At scale, correlating crashes to the previous kernel version enables
|
||||
faster root cause analysis when issues only occur in specific kernel
|
||||
transition scenarios.
|
||||
|
||||
debugfs Interfaces
|
||||
==================
|
||||
|
||||
|
|
@ -80,5 +119,5 @@ stabilized.
|
|||
it finished to interpret their metadata.
|
||||
|
||||
``/sys/kernel/debug/kho/in/sub_fdts/``
|
||||
Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs
|
||||
Similar to ``kho/out/sub_fdts/``, but contains sub blobs
|
||||
of KHO producers passed from the old kernel.
|
||||
|
|
|
|||
|
|
@ -40,3 +40,33 @@ how to translate the device into a serial number from SCSI EVPD 0x80::
|
|||
|
||||
echo "fencing client ${CLIENT} serial ${EVPD}" >> /var/log/pnfsd-fence.log
|
||||
EOF
|
||||
|
||||
If the nfsd server needs to fence a non-responding client and the
|
||||
fencing operation fails, the server logs a warning message in the
|
||||
system log with the following format:
|
||||
|
||||
FENCE failed client[IP_address] clid[#n] device[dev_name]
|
||||
|
||||
where:
|
||||
|
||||
- IP_address: refers to the IP address of the affected client.
|
||||
- #n: indicates the unique client identifier.
|
||||
- dev_name: specifies the name of the block device related
|
||||
to the fencing attempt.
|
||||
|
||||
The server will repeatedly retry the operation indefinitely. During
|
||||
this time, access to the affected file is restricted for all other
|
||||
clients. This is to prevent potential data corruption if multiple
|
||||
clients access the same file simultaneously.
|
||||
|
||||
To restore access to the affected file for other clients, the admin
|
||||
needs to take the following actions:
|
||||
|
||||
- shutdown or power off the client being fenced.
|
||||
- manually expire the client to release all its state on the server::
|
||||
|
||||
echo 'expire' > /proc/fs/nfsd/clients/clid/ctl
|
||||
|
||||
where:
|
||||
|
||||
- clid: is the unique client identifier displayed in the system log.
|
||||
|
|
|
|||
|
|
@ -22,3 +22,34 @@ option and the underlying SCSI device support persistent reservations.
|
|||
On the client make sure the kernel has the CONFIG_PNFS_BLOCK option
|
||||
enabled, and the file system is mounted using the NFSv4.1 protocol
|
||||
version (mount -o vers=4.1).
|
||||
|
||||
If the nfsd server needs to fence a non-responding client and the
|
||||
fencing operation fails, the server logs a warning message in the
|
||||
system log with the following format:
|
||||
|
||||
FENCE failed client[IP_address] clid[#n] device[dev_name]
|
||||
|
||||
where:
|
||||
|
||||
- IP_address: refers to the IP address of the affected client.
|
||||
- #n: indicates the unique client identifier.
|
||||
- dev_name: specifies the name of the block device related
|
||||
to the fencing attempt.
|
||||
|
||||
The server will repeatedly retry the operation indefinitely. During
|
||||
this time, access to the affected file is restricted for all other
|
||||
clients. This is to prevent potential data corruption if multiple
|
||||
clients access the same file simultaneously.
|
||||
|
||||
To restore access to the affected file for other clients, the admin
|
||||
needs to take the following actions:
|
||||
|
||||
- shutdown or power off the client being fenced.
|
||||
- manually expire the client to release all its state on the server::
|
||||
|
||||
echo 'expire' > /proc/fs/nfsd/clients/clid/ctl
|
||||
|
||||
where:
|
||||
|
||||
- clid: is the unique client identifier displayed in the system log.
|
||||
|
||||
|
|
|
|||
|
|
@ -202,6 +202,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA|
|
||||
| | | #562869,1047329 | |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ S/390 PCI
|
|||
|
||||
Authors:
|
||||
- Pierre Morel
|
||||
- Niklas Schnelle
|
||||
|
||||
Copyright, IBM Corp. 2020
|
||||
|
||||
|
|
@ -27,14 +28,16 @@ Command line parameters
|
|||
debugfs entries
|
||||
---------------
|
||||
|
||||
The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
|
||||
The S/390 debug feature (s390dbf) generates views to hold various debug results
|
||||
in sysfs directories of the form:
|
||||
|
||||
* /sys/kernel/debug/s390dbf/pci_*/
|
||||
|
||||
For example:
|
||||
|
||||
- /sys/kernel/debug/s390dbf/pci_msg/sprintf
|
||||
Holds messages from the processing of PCI events, like machine check handling
|
||||
|
||||
holds messages from the processing of PCI events, like machine check handling
|
||||
and setting of global functionality, like UID checking.
|
||||
|
||||
Change the level of logging to be more or less verbose by piping
|
||||
|
|
@ -47,87 +50,141 @@ Sysfs entries
|
|||
|
||||
Entries specific to zPCI functions and entries that hold zPCI information.
|
||||
|
||||
* /sys/bus/pci/slots/XXXXXXXX
|
||||
* /sys/bus/pci/slots/XXXXXXXX:
|
||||
|
||||
The slot entries are set up using the function identifier (FID) of the
|
||||
PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
|
||||
with 0 padding and lower case hexadecimal digits.
|
||||
The slot entries are set up using the function identifier (FID) of the PCI
|
||||
function as slot name. The format depicted as XXXXXXXX above is 8 hexadecimal
|
||||
digits with 0 padding and lower case hexadecimal digits.
|
||||
|
||||
- /sys/bus/pci/slots/XXXXXXXX/power
|
||||
|
||||
In addition to using the FID as the name of the slot, the slot directory
|
||||
also contains the following s390-specific slot attributes.
|
||||
|
||||
- uid:
|
||||
The User-defined identifier (UID) of the function which may be configured
|
||||
by this slot. See also the corresponding attribute of the device.
|
||||
|
||||
A physical function that currently supports a virtual function cannot be
|
||||
powered off until all virtual functions are removed with:
|
||||
echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
|
||||
echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
|
||||
|
||||
* /sys/bus/pci/devices/XXXX:XX:XX.X/
|
||||
* /sys/bus/pci/devices/DDDD:BB:dd.f/:
|
||||
|
||||
- function_id
|
||||
A zPCI function identifier that uniquely identifies the function in the Z server.
|
||||
- function_id:
|
||||
The zPCI function identifier (FID) is a 32-bit hexadecimal value that
|
||||
uniquely identifies the PCI function. Unless the hypervisor provides
|
||||
a virtual FID e.g. on KVM this identifier is unique across the machine even
|
||||
between different partitions.
|
||||
|
||||
- function_handle
|
||||
Low-level identifier used for a configured PCI function.
|
||||
It might be useful for debugging.
|
||||
- function_handle:
|
||||
This 32-bit hexadecimal value is a low-level identifier used for a PCI
|
||||
function. Note that the function handle may be changed and become invalid
|
||||
on PCI events and when enabling/disabling the PCI function.
|
||||
|
||||
- pchid
|
||||
Model-dependent location of the I/O adapter.
|
||||
- pchid:
|
||||
This 16-bit hexadecimal value encodes a model-dependent location for
|
||||
the PCI function.
|
||||
|
||||
- pfgid
|
||||
PCI function group ID, functions that share identical functionality
|
||||
- pfgid:
|
||||
PCI function group ID; functions that share identical functionality
|
||||
use a common identifier.
|
||||
A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
|
||||
|
||||
- vfn
|
||||
- vfn:
|
||||
The virtual function number, from 1 to N for virtual functions,
|
||||
0 for physical functions.
|
||||
|
||||
- pft
|
||||
The PCI function type
|
||||
- pft:
|
||||
The PCI function type is an s390-specific type attribute. It indicates
|
||||
a more general, usage oriented, type than PCI Specification
|
||||
class/vendor/device identifiers. That is PCI functions with the same pft
|
||||
value may be backed by different hardware implementations. At the same time
|
||||
apart from unclassified functions (pft is 0x00) the same pft value
|
||||
generally implies a similar usage model. At the same time the same
|
||||
PCI hardware device may appear with different pft values when in a
|
||||
different usage model. For example NETD and NETH VFs may be implemented
|
||||
by the same PCI hardware device but in NETD the parent Physical Function
|
||||
is user managed while with NETH it is platform managed.
|
||||
|
||||
- port
|
||||
The port corresponds to the physical port the function is attached to.
|
||||
It also gives an indication of the physical function a virtual function
|
||||
is attached to.
|
||||
Currently the following PFT values are defined:
|
||||
|
||||
- uid
|
||||
The user identifier (UID) may be defined as part of the machine
|
||||
configuration or the z/VM or KVM guest configuration. If the accompanying
|
||||
uid_is_unique attribute is 1 the platform guarantees that the UID is unique
|
||||
within that instance and no devices with the same UID can be attached
|
||||
during the lifetime of the system.
|
||||
- 0x00 (UNC): Unclassified
|
||||
- 0x02 (ROCE): RoCE Express
|
||||
- 0x05 (ISM): Internal Shared Memory
|
||||
- 0x0a (ROC2): RoCE Express 2
|
||||
- 0x0b (NVMe): NVMe
|
||||
- 0x0c (NETH): Network Express hybrid
|
||||
- 0x0d (CNW): Cloud Network Adapter
|
||||
- 0x0f (NETD): Network Express direct
|
||||
|
||||
- uid_is_unique
|
||||
Indicates whether the user identifier (UID) is guaranteed to be and remain
|
||||
unique within this Linux instance.
|
||||
- port:
|
||||
The port is a decimal value corresponding to the physical port the function
|
||||
is attached to. Virtual Functions (VFs) share the port with their parent
|
||||
Physical Function (PF). A value of 0 indicates that the port attribute is
|
||||
not applicable for that PCI function type.
|
||||
|
||||
- pfip/segmentX
|
||||
- uid:
|
||||
The user-defined identifier (UID) for a PCI function is a 32-bit
|
||||
hexadecimal value. It is defined on a per instance basis as part of the
|
||||
partition, KVM guest, or z/VM guest configuration. If UID Checking is
|
||||
enabled the platform ensures that the UID is unique within that instance
|
||||
and no two PCI functions with the same UID will be visible to the instance.
|
||||
|
||||
Independent of this guarantee and unlike the function ID (FID) the UID may
|
||||
be the same in different partitions within the same machine. This allows to
|
||||
create PCI configurations in multiple partitions to be identical in the
|
||||
UID-namespace.
|
||||
|
||||
- uid_is_unique:
|
||||
A 0 or 1 flag indicating whether the user-defined identifier (UID) is
|
||||
guaranteed to be and remain unique within this Linux instance. This
|
||||
platform feature is called UID Checking.
|
||||
|
||||
- pfip/segmentX:
|
||||
The segments determine the isolation of a function.
|
||||
They correspond to the physical path to the function.
|
||||
The more the segments are different, the more the functions are isolated.
|
||||
|
||||
- fidparm:
|
||||
Contains an 8-bit-per-PCI function parameter field in hexadecimal provided
|
||||
by the platform. The meaning of this field is PCI function type specific.
|
||||
For NETH VFs a value of 0x01 indicates that the function supports
|
||||
promiscuous mode.
|
||||
|
||||
* /sys/firmware/clp/uid_checking:
|
||||
|
||||
In addition to the per-device uid_is_unique attribute this presents a
|
||||
global indication of whether UID Checking is enabled. This allows users
|
||||
to check for UID Checking even when no PCI functions are configured.
|
||||
|
||||
Enumeration and hotplug
|
||||
=======================
|
||||
|
||||
The PCI address consists of four parts: domain, bus, device and function,
|
||||
and is of this form: DDDD:BB:dd.f
|
||||
and is of this form: DDDD:BB:dd.f.
|
||||
|
||||
* When not using multi-functions (norid is set, or the firmware does not
|
||||
support multi-functions):
|
||||
* For a PCI function for which the platform does not expose the RID, the
|
||||
pci=norid kernel parameter is used, or a so-called isolated Virtual Function
|
||||
which does have RID information but is used without its parent Physical
|
||||
Function being part of the same PCI configuration:
|
||||
|
||||
- There is only one function per domain.
|
||||
|
||||
- The domain is set from the zPCI function's UID as defined during the
|
||||
LPAR creation.
|
||||
- The domain is set from the zPCI function's UID if UID Checking is on;
|
||||
otherwise the domain ID is generated dynamically and is not stable
|
||||
across reboots or hot plug.
|
||||
|
||||
* When using multi-functions (norid parameter is not set),
|
||||
zPCI functions are addressed differently:
|
||||
* For a PCI function for which the platform exposes the RID and which
|
||||
is not an Isolated Virtual Function:
|
||||
|
||||
- There is still only one bus per domain.
|
||||
|
||||
- There can be up to 256 functions per bus.
|
||||
- There can be up to 256 PCI functions per bus.
|
||||
|
||||
- The domain part of the address of all functions for
|
||||
a multi-Function device is set from the zPCI function's UID as defined
|
||||
in the LPAR creation for the function zero.
|
||||
- The domain part of the address of all functions within the same topology is
|
||||
that of the configured PCI function with the lowest devfn within that
|
||||
topology.
|
||||
|
||||
- New functions will only be ready for use after the function zero
|
||||
(the function with devfn 0) has been enumerated.
|
||||
- Virtual Functions generated by an SR-IOV capable Physical Function only
|
||||
become visible once SR-IOV is enabled.
|
||||
|
|
|
|||
|
|
@ -13,6 +13,7 @@ for cryptographic use cases, as well as programming examples.
|
|||
:caption: Table of contents
|
||||
:maxdepth: 2
|
||||
|
||||
libcrypto
|
||||
intro
|
||||
api-intro
|
||||
architecture
|
||||
|
|
@ -27,4 +28,3 @@ for cryptographic use cases, as well as programming examples.
|
|||
descore-readme
|
||||
device_drivers/index
|
||||
krb5
|
||||
sha3
|
||||
|
|
|
|||
19
Documentation/crypto/libcrypto-blockcipher.rst
Normal file
19
Documentation/crypto/libcrypto-blockcipher.rst
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
Block ciphers
|
||||
=============
|
||||
|
||||
AES
|
||||
---
|
||||
|
||||
Support for the AES block cipher.
|
||||
|
||||
.. kernel-doc:: include/crypto/aes.h
|
||||
|
||||
DES
|
||||
---
|
||||
|
||||
Support for the DES block cipher. This algorithm is obsolete and is supported
|
||||
only for backwards compatibility.
|
||||
|
||||
.. kernel-doc:: include/crypto/des.h
|
||||
86
Documentation/crypto/libcrypto-hash.rst
Normal file
86
Documentation/crypto/libcrypto-hash.rst
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
Hash functions, MACs, and XOFs
|
||||
==============================
|
||||
|
||||
AES-CMAC and AES-XCBC-MAC
|
||||
-------------------------
|
||||
|
||||
Support for the AES-CMAC and AES-XCBC-MAC message authentication codes.
|
||||
|
||||
.. kernel-doc:: include/crypto/aes-cbc-macs.h
|
||||
|
||||
BLAKE2b
|
||||
-------
|
||||
|
||||
Support for the BLAKE2b cryptographic hash function.
|
||||
|
||||
.. kernel-doc:: include/crypto/blake2b.h
|
||||
|
||||
BLAKE2s
|
||||
-------
|
||||
|
||||
Support for the BLAKE2s cryptographic hash function.
|
||||
|
||||
.. kernel-doc:: include/crypto/blake2s.h
|
||||
|
||||
GHASH and POLYVAL
|
||||
-----------------
|
||||
|
||||
Support for the GHASH and POLYVAL universal hash functions. These algorithms
|
||||
are used only as internal components of other algorithms.
|
||||
|
||||
.. kernel-doc:: include/crypto/gf128hash.h
|
||||
|
||||
MD5
|
||||
---
|
||||
|
||||
Support for the MD5 cryptographic hash function and HMAC-MD5. This algorithm is
|
||||
obsolete and is supported only for backwards compatibility.
|
||||
|
||||
.. kernel-doc:: include/crypto/md5.h
|
||||
|
||||
NH
|
||||
--
|
||||
|
||||
Support for the NH universal hash function. This algorithm is used only as an
|
||||
internal component of other algorithms.
|
||||
|
||||
.. kernel-doc:: include/crypto/nh.h
|
||||
|
||||
Poly1305
|
||||
--------
|
||||
|
||||
Support for the Poly1305 universal hash function. This algorithm is used only
|
||||
as an internal component of other algorithms.
|
||||
|
||||
.. kernel-doc:: include/crypto/poly1305.h
|
||||
|
||||
SHA-1
|
||||
-----
|
||||
|
||||
Support for the SHA-1 cryptographic hash function and HMAC-SHA1. This algorithm
|
||||
is obsolete and is supported only for backwards compatibility.
|
||||
|
||||
.. kernel-doc:: include/crypto/sha1.h
|
||||
|
||||
SHA-2
|
||||
-----
|
||||
|
||||
Support for the SHA-2 family of cryptographic hash functions, including SHA-224,
|
||||
SHA-256, SHA-384, and SHA-512. This also includes their corresponding HMACs:
|
||||
HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512.
|
||||
|
||||
.. kernel-doc:: include/crypto/sha2.h
|
||||
|
||||
SHA-3
|
||||
-----
|
||||
|
||||
The SHA-3 functions are documented in :ref:`sha3`.
|
||||
|
||||
SM3
|
||||
---
|
||||
|
||||
Support for the SM3 cryptographic hash function.
|
||||
|
||||
.. kernel-doc:: include/crypto/sm3.h
|
||||
11
Documentation/crypto/libcrypto-signature.rst
Normal file
11
Documentation/crypto/libcrypto-signature.rst
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
Digital signature algorithms
|
||||
============================
|
||||
|
||||
ML-DSA
|
||||
------
|
||||
|
||||
Support for the ML-DSA digital signature algorithm.
|
||||
|
||||
.. kernel-doc:: include/crypto/mldsa.h
|
||||
6
Documentation/crypto/libcrypto-utils.rst
Normal file
6
Documentation/crypto/libcrypto-utils.rst
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
Utility functions
|
||||
=================
|
||||
|
||||
.. kernel-doc:: include/crypto/utils.h
|
||||
165
Documentation/crypto/libcrypto.rst
Normal file
165
Documentation/crypto/libcrypto.rst
Normal file
|
|
@ -0,0 +1,165 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
==============
|
||||
Crypto library
|
||||
==============
|
||||
|
||||
``lib/crypto/`` provides faster and easier access to cryptographic algorithms
|
||||
than the traditional crypto API.
|
||||
|
||||
Each cryptographic algorithm is supported via a set of dedicated functions.
|
||||
"Crypto agility", where needed, is left to calling code.
|
||||
|
||||
The crypto library functions are intended to be boring and straightforward, and
|
||||
to follow familiar conventions. Their primary documentation is their (fairly
|
||||
extensive) kernel-doc. This page just provides some extra high-level context.
|
||||
|
||||
Note that the crypto library isn't entirely new. ``lib/`` has contained some
|
||||
crypto functions since 2005. Rather, it's just an approach that's been expanded
|
||||
over time as it's been found to work well. It also largely just matches how the
|
||||
kernel already does things elsewhere.
|
||||
|
||||
Scope and intended audience
|
||||
===========================
|
||||
|
||||
The crypto library documentation is primarily meant for kernel developers who
|
||||
need to use a particular cryptographic algorithm(s) in kernel code. For
|
||||
example, "I just need to compute a SHA-256 hash." A secondary audience is
|
||||
developers working on the crypto algorithm implementations themselves.
|
||||
|
||||
If you're looking for more general information about cryptography, like the
|
||||
differences between the different crypto algorithms or how to select an
|
||||
appropriate algorithm, you should refer to external sources which cover that
|
||||
type of information much more comprehensively. If you need help selecting
|
||||
algorithms for a new kernel feature that doesn't already have its algorithms
|
||||
predefined, please reach out to ``linux-crypto@vger.kernel.org`` for advice.
|
||||
|
||||
Code organization
|
||||
=================
|
||||
|
||||
- ``lib/crypto/*.c``: the crypto algorithm implementations
|
||||
|
||||
- ``lib/crypto/$(SRCARCH)/``: architecture-specific code for crypto algorithms.
|
||||
It is here rather than somewhere in ``arch/`` partly because this allows
|
||||
generic and architecture-optimized code to be easily built into a single
|
||||
loadable module (when the algorithm is set to 'm' in the kconfig).
|
||||
|
||||
- ``lib/crypto/tests/``: KUnit tests for the crypto algorithms
|
||||
|
||||
- ``include/crypto/``: crypto headers, for both the crypto library and the
|
||||
traditional crypto API
|
||||
|
||||
Generally, there is one kernel module per algorithm. Sometimes related
|
||||
algorithms are grouped into one module. There is intentionally no common
|
||||
framework, though there are some utility functions that multiple algorithms use.
|
||||
|
||||
Each algorithm module is controlled by a tristate kconfig symbol
|
||||
``CRYPTO_LIB_$(ALGORITHM)``. As is the norm for library functions in the
|
||||
kernel, these are hidden symbols which don't show up in the kconfig menu.
|
||||
Instead, they are just selected by all the kconfig symbols that need them.
|
||||
|
||||
Many of the algorithms have multiple implementations: a generic implementation
|
||||
and architecture-optimized implementation(s). Each module initialization
|
||||
function, or initcall in the built-in case, automatically enables the best
|
||||
implementation based on the available CPU features.
|
||||
|
||||
Note that the crypto library doesn't use the ``crypto/``,
|
||||
``arch/$(SRCARCH)/crypto/``, or ``drivers/crypto/`` directories. These
|
||||
directories are used by the traditional crypto API. When possible, algorithms
|
||||
in the traditional crypto API are implemented by calls into the library.
|
||||
|
||||
Advantages
|
||||
==========
|
||||
|
||||
Some of the advantages of the library over the traditional crypto API are:
|
||||
|
||||
- The library functions tend to be much easier to use. For example, a hash
|
||||
value can be computed using only a single function call. Most of the library
|
||||
functions always succeed and return void, eliminating the need to write
|
||||
error-handling code. Most also accept standard virtual addresses, rather than
|
||||
scatterlists which are difficult and less efficient to work with.
|
||||
|
||||
- The library functions are usually faster, especially for short inputs. They
|
||||
call the crypto algorithms directly without inefficient indirect calls, memory
|
||||
allocations, string parsing, lookups in an algorithm registry, and other
|
||||
unnecessary API overhead. Architecture-optimized code is enabled by default.
|
||||
|
||||
- The library functions use standard link-time dependencies instead of
|
||||
error-prone dynamic loading by name. There's no need for workarounds such as
|
||||
forcing algorithms to be built-in or adding module soft dependencies.
|
||||
|
||||
- The library focuses on the approach that works the best on the vast majority
|
||||
of systems: CPU-based implementations of the crypto algorithms, utilizing
|
||||
on-CPU acceleration (such as AES instructions) when available.
|
||||
|
||||
- The library uses standard KUnit tests, rather than custom ad-hoc tests.
|
||||
|
||||
- The library tends to have higher assurance implementations of the crypto
|
||||
algorithms. This is both due to its simpler design and because more of its
|
||||
code is being regularly tested.
|
||||
|
||||
- The library supports features that don't fit into the rigid framework of the
|
||||
traditional crypto API, for example interleaved hashing and XOFs.
|
||||
|
||||
When to use it
|
||||
==============
|
||||
|
||||
In-kernel users should use the library (rather than the traditional crypto API)
|
||||
whenever possible. Many subsystems have already been converted. It usually
|
||||
simplifies their code significantly and improves performance.
|
||||
|
||||
Some kernel features allow userspace to provide an arbitrary string that selects
|
||||
an arbitrary algorithm from the traditional crypto API by name. These features
|
||||
generally will have to keep using the traditional crypto API for backwards
|
||||
compatibility.
|
||||
|
||||
Note: new kernel features shouldn't support every algorithm, but rather make a
|
||||
deliberate choice about what algorithm(s) to support. History has shown that
|
||||
making a deliberate, thoughtful choice greatly simplifies code maintenance,
|
||||
reduces the chance for mistakes (such as using an obsolete, insecure, or
|
||||
inappropriate algorithm), and makes your feature easier to use.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
The crypto library uses standard KUnit tests. Like many of the kernel's other
|
||||
KUnit tests, they are included in the set of tests that is run by
|
||||
``tools/testing/kunit/kunit.py run --alltests``.
|
||||
|
||||
A ``.kunitconfig`` file is also provided to run just the crypto library tests.
|
||||
For example, here's how to run them in user-mode Linux:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/
|
||||
|
||||
Many of the crypto algorithms have architecture-optimized implementations.
|
||||
Testing those requires building an appropriate kernel and running the tests
|
||||
either in QEMU or on appropriate hardware. Here's one example with QEMU:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/ --arch=arm64 --make_options LLVM=1
|
||||
|
||||
Depending on the code being tested, flags may need to be passed to QEMU to
|
||||
emulate the correct type of hardware for the code to be reached.
|
||||
|
||||
Since correctness is essential in cryptographic code, new architecture-optimized
|
||||
code is accepted only if it can be tested in QEMU.
|
||||
|
||||
Note: the crypto library also includes FIPS 140 self-tests. These are
|
||||
lightweight, are designed specifically to meet FIPS 140 requirements, and exist
|
||||
*only* to meet those requirements. Normal testing done by kernel developers and
|
||||
integrators should use the much more comprehensive KUnit tests instead.
|
||||
|
||||
API documentation
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
libcrypto-blockcipher
|
||||
libcrypto-hash
|
||||
libcrypto-signature
|
||||
libcrypto-utils
|
||||
sha3
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
.. _sha3:
|
||||
|
||||
==========================
|
||||
SHA-3 Algorithm Collection
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -21,6 +21,17 @@ properties:
|
|||
- const: marvell,armada-ap806-dual
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description:
|
||||
Falcon (DB-98CX85x0) Development board COM Express Carrier plus
|
||||
Armada 7020 SoC COM Express CPU module
|
||||
items:
|
||||
- const: marvell,armada7020-falcon-carrier
|
||||
- const: marvell,db-falcon-carrier
|
||||
- const: marvell,armada7020-cpu-module
|
||||
- const: marvell,armada7020
|
||||
- const: marvell,armada-ap806-dual
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description: Armada 7040 SoC
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ maintainers:
|
|||
- Robin van der Gracht <robin@protonic.nl>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/input/input.yaml#
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
properties:
|
||||
|
|
@ -33,9 +34,7 @@ properties:
|
|||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
debounce-delay-ms:
|
||||
maxItems: 1
|
||||
description: Debouncing interval time in milliseconds
|
||||
debounce-delay-ms: true
|
||||
|
||||
linux,keymap: true
|
||||
|
||||
|
|
|
|||
|
|
@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
|
|||
|
||||
maintainers:
|
||||
- Benson Leung <bleung@chromium.org>
|
||||
- Prashant Malani <pmalani@chromium.org>
|
||||
- Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
|
||||
- Andrei Kuchynski <akuchynski@chromium.org>
|
||||
- Łukasz Bartosik <ukaszb@chromium.org>
|
||||
- Jameson Thies <jthies@google.com>
|
||||
|
||||
description:
|
||||
Chrome OS devices have an Embedded Controller(EC) which has access to
|
||||
Type C port state. This node is intended to allow the host to read and
|
||||
control the Type C ports. The node for this device should be under a
|
||||
cros-ec node like google,cros-ec-spi.
|
||||
control the Type C ports. This binding is compatible with both the
|
||||
cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver
|
||||
supports the host command interface used by the Chrome OS EC with a
|
||||
built-in Type-C port manager and external Type-C Port Controller
|
||||
(TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector
|
||||
System Software (UCSI) interface used by the Chrome OS EC when the
|
||||
platform has a separate power delivery controller (PDC). The node for
|
||||
this device should be under a cros-ec node like google,cros-ec-spi.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: google,cros-ec-typec
|
||||
enum:
|
||||
- google,cros-ec-typec
|
||||
- google,cros-ec-ucsi
|
||||
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ properties:
|
|||
- enum:
|
||||
- airoha,en7523-scu
|
||||
- airoha,en7581-scu
|
||||
- econet,en751221-scu
|
||||
|
||||
reg:
|
||||
items:
|
||||
|
|
@ -67,7 +68,9 @@ allOf:
|
|||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: airoha,en7581-scu
|
||||
enum:
|
||||
- airoha,en7581-scu
|
||||
- econet,en751221-scu
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
|
|
@ -98,3 +101,4 @@ examples:
|
|||
#reset-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -1,196 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-div.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Baikal-T1 Clock Control Unit Dividers
|
||||
|
||||
maintainers:
|
||||
- Serge Semin <fancer.lancer@gmail.com>
|
||||
|
||||
description: |
|
||||
Clocks Control Unit is the core of Baikal-T1 SoC System Controller
|
||||
responsible for the chip subsystems clocking and resetting. The CCU is
|
||||
connected with an external fixed rate oscillator, which signal is transformed
|
||||
into clocks of various frequencies and then propagated to either individual
|
||||
IP-blocks or to groups of blocks (clock domains). The transformation is done
|
||||
by means of an embedded into CCU PLLs and gateable/non-gateable dividers. The
|
||||
later ones are described in this binding. Each clock domain can be also
|
||||
individually reset by using the domain clocks divider configuration
|
||||
registers. Baikal-T1 CCU is logically divided into the next components:
|
||||
1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but
|
||||
in general can provide any frequency supported by the CCU PLLs).
|
||||
2) PLLs clocks generators (PLLs).
|
||||
3) AXI-bus clock dividers (AXI) - described in this binding file.
|
||||
4) System devices reference clock dividers (SYS) - described in this binding
|
||||
file.
|
||||
which are connected with each other as shown on the next figure:
|
||||
|
||||
+---------------+
|
||||
| Baikal-T1 CCU |
|
||||
| +----+------|- MIPS P5600 cores
|
||||
| +-|PLLs|------|- DDR controller
|
||||
| | +----+ |
|
||||
+----+ | | | | |
|
||||
|XTAL|--|-+ | | +---+-|
|
||||
+----+ | | | +-|AXI|-|- AXI-bus
|
||||
| | | +---+-|
|
||||
| | | |
|
||||
| | +----+---+-|- APB-bus
|
||||
| +-------|SYS|-|- Low-speed Devices
|
||||
| +---+-|- High-speed Devices
|
||||
+---------------+
|
||||
|
||||
Each sub-block is represented as a separate DT node and has an individual
|
||||
driver to be bound with.
|
||||
|
||||
In order to create signals of wide range frequencies the external oscillator
|
||||
output is primarily connected to a set of CCU PLLs. Some of PLLs CLKOUT are
|
||||
then passed over CCU dividers to create signals required for the target clock
|
||||
domain (like AXI-bus or System Device consumers). The dividers have the
|
||||
following structure:
|
||||
|
||||
+--------------+
|
||||
CLKIN --|->+----+ 1|\ |
|
||||
SETCLK--|--|/DIV|->| | |
|
||||
CLKDIV--|--| | | |-|->CLKLOUT
|
||||
LOCK----|--+----+ | | |
|
||||
| |/ |
|
||||
| | |
|
||||
EN------|-----------+ |
|
||||
RST-----|--------------|->RSTOUT
|
||||
+--------------+
|
||||
|
||||
where CLKIN is the reference clock coming either from CCU PLLs or from an
|
||||
external clock oscillator, SETCLK - a command to update the output clock in
|
||||
accordance with a set divider, CLKDIV - clocks divider, LOCK - a signal of
|
||||
the output clock stabilization, EN - enable/disable the divider block,
|
||||
RST/RSTOUT - reset clocks domain signal. Depending on the consumer IP-core
|
||||
peculiarities the dividers may lack of some functionality depicted on the
|
||||
figure above (like EN, CLKDIV/LOCK/SETCLK). In this case the corresponding
|
||||
clock provider just doesn't expose either switching functions, or the rate
|
||||
configuration, or both of them.
|
||||
|
||||
The clock dividers, which output clock is then consumed by the SoC individual
|
||||
devices, are united into a single clocks provider called System Devices CCU.
|
||||
Similarly the dividers with output clocks utilized as AXI-bus reference clocks
|
||||
are called AXI-bus CCU. Both of them use the common clock bindings with no
|
||||
custom properties. The list of exported clocks and reset signals can be found
|
||||
in the files: 'include/dt-bindings/clock/bt1-ccu.h' and
|
||||
'include/dt-bindings/reset/bt1-ccu.h'. Since System Devices and AXI-bus CCU
|
||||
are a part of the Baikal-T1 SoC System Controller their DT nodes are supposed
|
||||
to be a children of later one.
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: baikal,bt1-ccu-axi
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: CCU SATA PLL output clock
|
||||
- description: CCU PCIe PLL output clock
|
||||
- description: CCU Ethernet PLL output clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: sata_clk
|
||||
- const: pcie_clk
|
||||
- const: eth_clk
|
||||
|
||||
else:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock
|
||||
- description: CCU SATA PLL output clock
|
||||
- description: CCU PCIe PLL output clock
|
||||
- description: CCU Ethernet PLL output clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ref_clk
|
||||
- const: sata_clk
|
||||
- const: pcie_clk
|
||||
- const: eth_clk
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- baikal,bt1-ccu-axi
|
||||
- baikal,bt1-ccu-sys
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
"#reset-cells":
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
|
||||
clock-names:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
examples:
|
||||
# AXI-bus Clock Control Unit node:
|
||||
- |
|
||||
#include <dt-bindings/clock/bt1-ccu.h>
|
||||
|
||||
clock-controller@1f04d030 {
|
||||
compatible = "baikal,bt1-ccu-axi";
|
||||
reg = <0x1f04d030 0x030>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
|
||||
clocks = <&ccu_pll CCU_SATA_PLL>,
|
||||
<&ccu_pll CCU_PCIE_PLL>,
|
||||
<&ccu_pll CCU_ETH_PLL>;
|
||||
clock-names = "sata_clk", "pcie_clk", "eth_clk";
|
||||
};
|
||||
# System Devices Clock Control Unit node:
|
||||
- |
|
||||
#include <dt-bindings/clock/bt1-ccu.h>
|
||||
|
||||
clock-controller@1f04d060 {
|
||||
compatible = "baikal,bt1-ccu-sys";
|
||||
reg = <0x1f04d060 0x0a0>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
|
||||
clocks = <&clk25m>,
|
||||
<&ccu_pll CCU_SATA_PLL>,
|
||||
<&ccu_pll CCU_PCIE_PLL>,
|
||||
<&ccu_pll CCU_ETH_PLL>;
|
||||
clock-names = "ref_clk", "sata_clk", "pcie_clk",
|
||||
"eth_clk";
|
||||
};
|
||||
# Required Clock Control Unit PLL node:
|
||||
- |
|
||||
ccu_pll: clock-controller@1f04d000 {
|
||||
compatible = "baikal,bt1-ccu-pll";
|
||||
reg = <0x1f04d000 0x028>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clocks = <&clk25m>;
|
||||
clock-names = "ref_clk";
|
||||
};
|
||||
...
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Baikal-T1 Clock Control Unit PLL
|
||||
|
||||
maintainers:
|
||||
- Serge Semin <fancer.lancer@gmail.com>
|
||||
|
||||
description: |
|
||||
Clocks Control Unit is the core of Baikal-T1 SoC System Controller
|
||||
responsible for the chip subsystems clocking and resetting. The CCU is
|
||||
connected with an external fixed rate oscillator, which signal is transformed
|
||||
into clocks of various frequencies and then propagated to either individual
|
||||
IP-blocks or to groups of blocks (clock domains). The transformation is done
|
||||
by means of PLLs and gateable/non-gateable dividers embedded into the CCU.
|
||||
It's logically divided into the next components:
|
||||
1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but
|
||||
in general can provide any frequency supported by the CCU PLLs).
|
||||
2) PLLs clocks generators (PLLs) - described in this binding file.
|
||||
3) AXI-bus clock dividers (AXI).
|
||||
4) System devices reference clock dividers (SYS).
|
||||
which are connected with each other as shown on the next figure:
|
||||
|
||||
+---------------+
|
||||
| Baikal-T1 CCU |
|
||||
| +----+------|- MIPS P5600 cores
|
||||
| +-|PLLs|------|- DDR controller
|
||||
| | +----+ |
|
||||
+----+ | | | | |
|
||||
|XTAL|--|-+ | | +---+-|
|
||||
+----+ | | | +-|AXI|-|- AXI-bus
|
||||
| | | +---+-|
|
||||
| | | |
|
||||
| | +----+---+-|- APB-bus
|
||||
| +-------|SYS|-|- Low-speed Devices
|
||||
| +---+-|- High-speed Devices
|
||||
+---------------+
|
||||
|
||||
Each CCU sub-block is represented as a separate dts-node and has an
|
||||
individual driver to be bound with.
|
||||
|
||||
In order to create signals of wide range frequencies the external oscillator
|
||||
output is primarily connected to a set of CCU PLLs. There are five PLLs
|
||||
to create a clock for the MIPS P5600 cores, the embedded DDR controller,
|
||||
SATA, Ethernet and PCIe domains. The last three domains though named by the
|
||||
biggest system interfaces in fact include nearly all of the rest SoC
|
||||
peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM core
|
||||
with an interface wrapper (so called safe PLL' clocks switcher) to simplify
|
||||
the PLL configuration procedure. The PLLs work as depicted on the next
|
||||
diagram:
|
||||
|
||||
+--------------------------+
|
||||
| |
|
||||
+-->+---+ +---+ +---+ | +---+ 0|\
|
||||
CLKF--->|/NF|--->|PFD|...|VCO|-+->|/OD|--->| |
|
||||
+---+ +->+---+ +---+ /->+---+ | |--->CLKOUT
|
||||
CLKOD---------C----------------+ 1| |
|
||||
+--------C--------------------------->|/
|
||||
| | ^
|
||||
Rclk-+->+---+ | |
|
||||
CLKR--->|/NR|-+ |
|
||||
+---+ |
|
||||
BYPASS--------------------------------------+
|
||||
BWADJ--->
|
||||
|
||||
where Rclk is the reference clock coming from XTAL, NR - reference clock
|
||||
divider, NF - PLL clock multiplier, OD - VCO output clock divider, CLKOUT -
|
||||
output clock, BWADJ is the PLL bandwidth adjustment parameter. At this moment
|
||||
the binding supports the PLL dividers configuration in accordance with a
|
||||
requested rate, while bypassing and bandwidth adjustment settings can be
|
||||
added in future if it gets to be necessary.
|
||||
|
||||
The PLLs CLKOUT is then either directly connected with the corresponding
|
||||
clocks consumer (like P5600 cores or DDR controller) or passed over a CCU
|
||||
divider to create a signal required for the clock domain.
|
||||
|
||||
The CCU PLL dts-node uses the common clock bindings with no custom
|
||||
parameters. The list of exported clocks can be found in
|
||||
'include/dt-bindings/clock/bt1-ccu.h'. Since CCU PLL is a part of the
|
||||
Baikal-T1 SoC System Controller its DT node is supposed to be a child of
|
||||
later one.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: baikal,bt1-ccu-pll
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
description: External reference clock
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: ref_clk
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
examples:
|
||||
# Clock Control Unit PLL node:
|
||||
- |
|
||||
clock-controller@1f04d000 {
|
||||
compatible = "baikal,bt1-ccu-pll";
|
||||
reg = <0x1f04d000 0x028>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clocks = <&clk25m>;
|
||||
clock-names = "ref_clk";
|
||||
};
|
||||
# Required external oscillator:
|
||||
- |
|
||||
clk25m: clock-oscillator-25m {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <25000000>;
|
||||
clock-output-names = "clk25m";
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/eswin,eic7700-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Eswin EIC7700 SoC clock controller
|
||||
|
||||
maintainers:
|
||||
- Yifeng Huang <huangyifeng@eswincomputing.com>
|
||||
- Xuyang Dong <dongxuyang@eswincomputing.com>
|
||||
|
||||
description:
|
||||
The clock controller generates and supplies clock to all the modules
|
||||
for eic7700 SoC.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: eswin,eic7700-clock
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: External 24MHz oscillator clock
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@51828000 {
|
||||
compatible = "eswin,eic7700-clock";
|
||||
reg = <0x51828000 0x300>;
|
||||
clocks = <&xtal24m>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
|
@ -10,10 +10,10 @@ maintainers:
|
|||
- Michael Walle <michael@walle.cc>
|
||||
|
||||
description: |
|
||||
It is possible to use the BCLK pin of a SAI module as a generic clock
|
||||
output. Some SoC are very constrained in their pin multiplexer
|
||||
configuration. Eg. pins can only be changed groups. For example, on the
|
||||
LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
|
||||
It is possible to use the BCLK or MCLK pin of a SAI module as a generic
|
||||
clock output. Some SoC are very constrained in their pin multiplexer
|
||||
configuration. E.g. pins can only be changed in groups. For example, on
|
||||
the LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
|
||||
the second pins are wasted. Using this binding it is possible to use the
|
||||
clock of the second SAI as a MCLK clock for an audio codec, for example.
|
||||
|
||||
|
|
@ -21,16 +21,45 @@ description: |
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,vf610-sai-clock
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx8mm-sai-clock
|
||||
- fsl,imx8mn-sai-clock
|
||||
- fsl,imx8mp-sai-clock
|
||||
- const: fsl,imx8mq-sai-clock
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx8mq-sai-clock
|
||||
- fsl,vf610-sai-clock
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- const: bus
|
||||
- const: mclk1
|
||||
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
maximum: 1
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: fsl,vf610-sai-clock
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
clock-names: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
|||
|
|
@ -29,20 +29,24 @@ properties:
|
|||
const: 1
|
||||
|
||||
clocks:
|
||||
minItems: 5
|
||||
items:
|
||||
- description: 24m osc
|
||||
- description: 32k osc
|
||||
- description: ckih1 clock input
|
||||
- description: anaclk1 clock input
|
||||
- description: anaclk2 clock input
|
||||
- description: clock input from enet ref pad
|
||||
|
||||
clock-names:
|
||||
minItems: 5
|
||||
items:
|
||||
- const: osc
|
||||
- const: ckil
|
||||
- const: ckih1
|
||||
- const: anaclk1
|
||||
- const: anaclk2
|
||||
- const: enet_ref_pad
|
||||
|
||||
fsl,pmic-stby-poweroff:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
|
|
|||
|
|
@ -29,18 +29,22 @@ properties:
|
|||
const: 1
|
||||
|
||||
clocks:
|
||||
minItems: 4
|
||||
items:
|
||||
- description: 32k osc
|
||||
- description: 24m osc
|
||||
- description: ipp_di0 clock input
|
||||
- description: ipp_di1 clock input
|
||||
- description: clock input from enet1 ref pad
|
||||
|
||||
clock-names:
|
||||
minItems: 4
|
||||
items:
|
||||
- const: ckil
|
||||
- const: osc
|
||||
- const: ipp_di0
|
||||
- const: ipp_di1
|
||||
- const: enet1_ref_pad
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,eliza-dispcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Display Clock & Reset Controller for Qualcomm Eliza SoC
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Display clock control module provides the clocks, resets and power
|
||||
domains on Qualcomm Eliza SoC platform.
|
||||
|
||||
See also:
|
||||
- include/dt-bindings/clock/qcom,eliza-dispcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,eliza-dispcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board Always On XO source
|
||||
- description: Display's AHB clock
|
||||
- description: sleep clock
|
||||
- description: Byte clock from DSI PHY0
|
||||
- description: Pixel clock from DSI PHY0
|
||||
- description: Byte clock from DSI PHY1
|
||||
- description: Pixel clock from DSI PHY1
|
||||
- description: Link clock from DP PHY0
|
||||
- description: VCO DIV clock from DP PHY0
|
||||
- description: Link clock from DP PHY1
|
||||
- description: VCO DIV clock from DP PHY1
|
||||
- description: Link clock from DP PHY2
|
||||
- description: VCO DIV clock from DP PHY2
|
||||
- description: Link clock from DP PHY3
|
||||
- description: VCO DIV clock from DP PHY3
|
||||
- description: HDMI link clock from HDMI PHY
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required-opps:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- '#power-domain-cells'
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
|
||||
#include <dt-bindings/clock/qcom,eliza-gcc.h>
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/power/qcom,rpmhpd.h>
|
||||
clock-controller@af00000 {
|
||||
compatible = "qcom,eliza-dispcc";
|
||||
reg = <0x0af00000 0x20000>;
|
||||
clocks = <&bi_tcxo_div2>,
|
||||
<&bi_tcxo_ao_div2>,
|
||||
<&gcc GCC_DISP_AHB_CLK>,
|
||||
<&sleep_clk>,
|
||||
<&dsi0_phy DSI_BYTE_PLL_CLK>,
|
||||
<&dsi0_phy DSI_PIXEL_PLL_CLK>,
|
||||
<&dsi1_phy DSI_BYTE_PLL_CLK>,
|
||||
<&dsi1_phy DSI_PIXEL_PLL_CLK>,
|
||||
<&dp0_phy 0>,
|
||||
<&dp0_phy 1>,
|
||||
<&dp1_phy 0>,
|
||||
<&dp1_phy 1>,
|
||||
<&dp2_phy 0>,
|
||||
<&dp2_phy 1>,
|
||||
<&dp3_phy 0>,
|
||||
<&dp3_phy 1>,
|
||||
<&hdmi_phy>;
|
||||
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
|
||||
power-domains = <&rpmhpd RPMHPD_MMCX>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
};
|
||||
...
|
||||
|
|
@ -4,14 +4,14 @@
|
|||
$id: http://devicetree.org/schemas/clock/qcom,glymur-dispcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Display Clock & Reset Controller on GLYMUR
|
||||
title: Qualcomm Display Clock & Reset Controller on Glymur SoC
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <taniya.das@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module which supports the clocks, resets and
|
||||
power domains for the MDSS instances on GLYMUR SoC.
|
||||
power domains for the MDSS instances on Glymur SoC.
|
||||
|
||||
See also:
|
||||
include/dt-bindings/clock/qcom,dispcc-glymur.h
|
||||
|
|
|
|||
|
|
@ -26,6 +26,8 @@ properties:
|
|||
enum:
|
||||
- qcom,ipq5018-cmn-pll
|
||||
- qcom,ipq5424-cmn-pll
|
||||
- qcom,ipq6018-cmn-pll
|
||||
- qcom,ipq8074-cmn-pll
|
||||
- qcom,ipq9574-cmn-pll
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -20,7 +20,9 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,glymur-gxclkctl
|
||||
- qcom,kaanapali-gxclkctl
|
||||
- qcom,sm8750-gxclkctl
|
||||
|
||||
power-domains:
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -35,9 +35,14 @@ properties:
|
|||
- description: UFS Phy Tx symbol 0 clock source
|
||||
- description: USB3 Phy wrapper pipe clock source
|
||||
|
||||
power-domains:
|
||||
items:
|
||||
- description: CX domain
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- power-domains
|
||||
- '#power-domain-cells'
|
||||
|
||||
allOf:
|
||||
|
|
@ -48,6 +53,7 @@ unevaluatedProperties: false
|
|||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/power/qcom,rpmhpd.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,milos-gcc";
|
||||
reg = <0x00100000 0x1f4200>;
|
||||
|
|
@ -59,6 +65,7 @@ examples:
|
|||
<&ufs_mem_phy 1>,
|
||||
<&ufs_mem_phy 2>,
|
||||
<&usb_1_qmpphy>;
|
||||
power-domains = <&rpmhpd RPMHPD_CX>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
|
|
|
|||
58
Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml
Normal file
58
Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,nord-gcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller on Nord SoC
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <taniya.das@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
domains on Nord SoC.
|
||||
|
||||
See also: include/dt-bindings/clock/qcom,nord-gcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,nord-gcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Sleep clock source
|
||||
- description: PCIE A Pipe clock source
|
||||
- description: PCIE B Pipe clock source
|
||||
- description: PCIE C Pipe clock source
|
||||
- description: PCIE D Pipe clock source
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- '#power-domain-cells'
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,nord-gcc";
|
||||
reg = <0x00100000 0x1f4200>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&sleep_clk>,
|
||||
<&pcie_a_pipe_clk>,
|
||||
<&pcie_b_pipe_clk>,
|
||||
<&pcie_c_pipe_clk>,
|
||||
<&pcie_d_pipe_clk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
||||
60
Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml
Normal file
60
Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,nord-negcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global North East Clock & Reset Controller on Nord SoC
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <taniya.das@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control (NE) module provides the clocks, resets
|
||||
and power domains on Nord SoC.
|
||||
|
||||
See also: include/dt-bindings/clock/qcom,nord-negcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,nord-negcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Sleep clock source
|
||||
- description: UFS Phy Rx symbol 0 clock source
|
||||
- description: UFS Phy Rx symbol 1 clock source
|
||||
- description: UFS Phy Tx symbol 0 clock source
|
||||
- description: USB3 Phy sec wrapper pipe clock source
|
||||
- description: USB3 Phy wrapper pipe clock source
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- '#power-domain-cells'
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@8900000 {
|
||||
compatible = "qcom,nord-negcc";
|
||||
reg = <0x08900000 0xf4200>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&sleep_clk>,
|
||||
<&ufs_phy_rx_symbol_0_clk>,
|
||||
<&ufs_phy_rx_symbol_1_clk>,
|
||||
<&ufs_phy_tx_symbol_0_clk>,
|
||||
<&usb3_phy_sec_pipe_clk>,
|
||||
<&usb3_phy_pipe_clk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
||||
55
Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml
Normal file
55
Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,nord-nwgcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global North West and South East Clock & Reset Controller
|
||||
on Nord SoC
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <taniya.das@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control (NW, SE) module provides the clocks, resets
|
||||
and power domains on Nord SoC.
|
||||
|
||||
See also:
|
||||
include/dt-bindings/clock/qcom,nord-nwgcc.h
|
||||
include/dt-bindings/clock/qcom,nord-segcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,nord-nwgcc
|
||||
- qcom,nord-segcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Sleep clock source
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- '#power-domain-cells'
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@8b00000 {
|
||||
compatible = "qcom,nord-nwgcc";
|
||||
reg = <0x08b00000 0xf4200>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&sleep_clk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -21,6 +21,7 @@ properties:
|
|||
- qcom,glymur-rpmh-clk
|
||||
- qcom,kaanapali-rpmh-clk
|
||||
- qcom,milos-rpmh-clk
|
||||
- qcom,nord-rpmh-clk
|
||||
- qcom,qcs615-rpmh-clk
|
||||
- qcom,qdu1000-rpmh-clk
|
||||
- qcom,sa8775p-rpmh-clk
|
||||
|
|
|
|||
|
|
@ -8,12 +8,14 @@ title: Qualcomm Graphics Clock & Reset Controller on SM8450
|
|||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
- Taniya Das <taniya.das@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides the clocks, resets and power
|
||||
domains on Qualcomm SoCs.
|
||||
|
||||
See also::
|
||||
See also:
|
||||
include/dt-bindings/clock/qcom,glymur-gpucc.h
|
||||
include/dt-bindings/clock/qcom,kaanapali-gpucc.h
|
||||
include/dt-bindings/clock/qcom,milos-gpucc.h
|
||||
include/dt-bindings/clock/qcom,sar2130p-gpucc.h
|
||||
|
|
@ -22,11 +24,13 @@ description: |
|
|||
include/dt-bindings/clock/qcom,sm8550-gpucc.h
|
||||
include/dt-bindings/reset/qcom,sm8450-gpucc.h
|
||||
include/dt-bindings/reset/qcom,sm8650-gpucc.h
|
||||
include/dt-bindings/reset/qcom,sm8750-gpucc.h
|
||||
include/dt-bindings/reset/qcom,x1e80100-gpucc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,glymur-gpucc
|
||||
- qcom,kaanapali-gpucc
|
||||
- qcom,milos-gpucc
|
||||
- qcom,sar2130p-gpucc
|
||||
|
|
@ -35,6 +39,7 @@ properties:
|
|||
- qcom,sm8475-gpucc
|
||||
- qcom,sm8550-gpucc
|
||||
- qcom,sm8650-gpucc
|
||||
- qcom,sm8750-gpucc
|
||||
- qcom,x1e80100-gpucc
|
||||
- qcom,x1p42100-gpucc
|
||||
|
||||
|
|
@ -44,6 +49,16 @@ properties:
|
|||
- description: GPLL0 main branch source
|
||||
- description: GPLL0 div branch source
|
||||
|
||||
power-domains:
|
||||
items:
|
||||
- description: A phandle to the MX power-domain
|
||||
- description: A phandle to the CX power-domain
|
||||
|
||||
required-opps:
|
||||
items:
|
||||
- description: A phandle to an OPP node describing MX performance points
|
||||
- description: A phandle to an OPP node describing CX performance points
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
|
|
@ -51,6 +66,16 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sm8750-gpucc
|
||||
then:
|
||||
required:
|
||||
- power-domains
|
||||
- required-opps
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ description: |
|
|||
domains on SM8450.
|
||||
|
||||
See also:
|
||||
include/dt-bindings/clock/qcom,glymur-videocc.h
|
||||
include/dt-bindings/clock/qcom,kaanapali-videocc.h
|
||||
include/dt-bindings/clock/qcom,sm8450-videocc.h
|
||||
include/dt-bindings/clock/qcom,sm8650-videocc.h
|
||||
|
|
@ -23,6 +24,7 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,glymur-videocc
|
||||
- qcom,kaanapali-videocc
|
||||
- qcom,sm8450-videocc
|
||||
- qcom,sm8475-videocc
|
||||
|
|
@ -63,6 +65,7 @@ allOf:
|
|||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,glymur-videocc
|
||||
- qcom,kaanapali-videocc
|
||||
- qcom,sm8450-videocc
|
||||
- qcom,sm8550-videocc
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ description: |
|
|||
See also:
|
||||
- include/dt-bindings/clock/qcom,eliza-tcsr.h
|
||||
- include/dt-bindings/clock/qcom,glymur-tcsr.h
|
||||
- include/dt-bindings/clock/qcom,nord-tcsrcc.h
|
||||
- include/dt-bindings/clock/qcom,sm8550-tcsr.h
|
||||
- include/dt-bindings/clock/qcom,sm8650-tcsr.h
|
||||
- include/dt-bindings/clock/qcom,sm8750-tcsr.h
|
||||
|
|
@ -29,6 +30,7 @@ properties:
|
|||
- qcom,glymur-tcsr
|
||||
- qcom,kaanapali-tcsr
|
||||
- qcom,milos-tcsr
|
||||
- qcom,nord-tcsrcc
|
||||
- qcom,sar2130p-tcsr
|
||||
- qcom,sm8550-tcsr
|
||||
- qcom,sm8650-tcsr
|
||||
|
|
|
|||
|
|
@ -35,6 +35,7 @@ properties:
|
|||
- samsung,exynosautov920-cmu-cpucl0
|
||||
- samsung,exynosautov920-cmu-cpucl1
|
||||
- samsung,exynosautov920-cmu-cpucl2
|
||||
- samsung,exynosautov920-cmu-g3d
|
||||
- samsung,exynosautov920-cmu-hsi0
|
||||
- samsung,exynosautov920-cmu-hsi1
|
||||
- samsung,exynosautov920-cmu-hsi2
|
||||
|
|
@ -287,6 +288,26 @@ allOf:
|
|||
- const: oscclk
|
||||
- const: noc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: samsung,exynosautov920-cmu-g3d
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (38.4 MHz)
|
||||
- description: CMU_G3D SWITCH clock (from CMU_TOP)
|
||||
- description: CMU_G3D NOCP clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: switch
|
||||
- const: nocp
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/tenstorrent,atlantis-prcm-rcpu.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Tenstorrent Atlantis PRCM (Power, Reset, Clock Management) Module
|
||||
|
||||
maintainers:
|
||||
- Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
|
||||
|
||||
description:
|
||||
Multifunctional register block found in Tenstorrent Atlantis SoC whose main
|
||||
function is to control clocks and resets. This block is instantiated multiple
|
||||
times in the SoC, each block controls clock and resets for a different
|
||||
subsystem. RCPU prcm serves low speed IO interfaces.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- tenstorrent,atlantis-prcm-rcpu
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
description:
|
||||
See <dt-bindings/clock/tenstorrent,atlantis-prcm-rcpu.h> for valid indices.
|
||||
|
||||
"#reset-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- "#clock-cells"
|
||||
- "#reset-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@a8000000 {
|
||||
compatible = "tenstorrent,atlantis-prcm-rcpu";
|
||||
reg = <0xa8000000 0x10000>;
|
||||
clocks = <&osc_24m>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
|
@ -300,6 +300,40 @@ properties:
|
|||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
maxItems: 4
|
||||
|
||||
sink-load-step:
|
||||
description: Indicates the preferred load step slew rate in mA/usec for
|
||||
the port (in sink mode). This property is defined in "6.5.13.7" of
|
||||
"USB Power Delivery Specification Revision 3.1 Version 1.8".
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [150, 500]
|
||||
default: 150
|
||||
|
||||
sink-load-characteristics:
|
||||
description: Indicates the port's (in sink mode) preferred load
|
||||
characteristics. Users can leverage SINK_LOAD_CHAR() defined in
|
||||
dt-bindings/usb/pd.h to populate this field. This property is defined in
|
||||
"6.5.13.8" of "USB Power Delivery Specification Revision 3.1 Version 1.8".
|
||||
$ref: /schemas/types.yaml#/definitions/uint16
|
||||
|
||||
sink-compliance:
|
||||
description: Represents the types of sources the sink device has been tested
|
||||
and certified with. This property is defined in "6.5.13.9" of
|
||||
"USB Power Delivery Specification Revision 3.1 Version 1.8"
|
||||
Bit 0 when set indicates it has been tested on LPS compliant source
|
||||
Bit 1 when set indicates it has been tested on PS1 compliant source
|
||||
Bit 2 when set indicates it has been tested on PS2 compliant source
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
maximum: 7
|
||||
|
||||
charging-adapter-pdp-milliwatt:
|
||||
description: This corresponds to the Power Delivery Profile rating of the
|
||||
charging adapter shipped or recommended for use with the connector port.
|
||||
This property is a requirement to infer the USB PD property
|
||||
"SPR Sink Operational PDP" given in "6.5.13.14" of
|
||||
"USB Power Delivery Specification Revision 3.1 Version 1.8".
|
||||
minimum: 0
|
||||
maximum: 100000
|
||||
|
||||
dependencies:
|
||||
pd-disable: [typec-power-opmode]
|
||||
sink-vdos-v1: [ sink-vdos ]
|
||||
|
|
@ -331,8 +365,9 @@ $defs:
|
|||
"Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
|
||||
Sink Capabilities Message, the order of each entry(PDO) should follow the
|
||||
PD spec chapter 6.4.1. Required for power sink and power dual role. User
|
||||
can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
|
||||
in dt-bindings/usb/pd.h.
|
||||
can specify the sink PDO array via
|
||||
PDO_FIXED/BATT/VAR/PPS_APDO/SPR_AVS_SNK_APDO() defined in
|
||||
dt-bindings/usb/pd.h.
|
||||
minItems: 1
|
||||
maxItems: 7
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Apple pre-DCP display controller MIPI interface
|
||||
|
||||
maintainers:
|
||||
- Sasha Finkelstein <fnkl.kernel@gmail.com>
|
||||
- Sasha Finkelstein <k@chaosmail.tech>
|
||||
|
||||
description:
|
||||
The MIPI controller part of the pre-DCP Apple display controller
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Apple pre-DCP display controller
|
||||
|
||||
maintainers:
|
||||
- Sasha Finkelstein <fnkl.kernel@gmail.com>
|
||||
- Sasha Finkelstein <k@chaosmail.tech>
|
||||
|
||||
description:
|
||||
A secondary display controller used to drive the "touchbar" on
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Apple "Summit" display panel
|
||||
|
||||
maintainers:
|
||||
- Sasha Finkelstein <fnkl.kernel@gmail.com>
|
||||
- Sasha Finkelstein <k@chaosmail.tech>
|
||||
|
||||
description:
|
||||
An OLED panel used as a touchbar on certain Apple laptops.
|
||||
|
|
|
|||
|
|
@ -42,6 +42,9 @@ properties:
|
|||
description:
|
||||
A port node to link the usb controller for the dual role switch.
|
||||
|
||||
connector:
|
||||
$ref: /schemas/connector/usb-connector.yaml#
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
|
|
|
|||
|
|
@ -27,7 +27,6 @@ properties:
|
|||
- gateworks,pld-gpio
|
||||
- ibm,ppc4xx-gpio
|
||||
- loongson,ls1x-gpio
|
||||
- maxim,max77620
|
||||
- nintendo,hollywood-gpio
|
||||
- nxp,pca9570
|
||||
- nxp,pca9571
|
||||
|
|
@ -86,7 +85,6 @@ allOf:
|
|||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- maxim,max77620
|
||||
- rockchip,rk3328-grf-gpio
|
||||
- ti,lp3943-gpio
|
||||
- ti,palmas-gpio
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Apple SoC GPU
|
||||
|
||||
maintainers:
|
||||
- Sasha Finkelstein <fnkl.kernel@gmail.com>
|
||||
- Sasha Finkelstein <k@chaosmail.tech>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -16,10 +16,15 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
|
||||
- amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
|
||||
- amlogic,meson-axg-i2c # AXG and compatible SoCs
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,t7-i2c
|
||||
- const: amlogic,meson-axg-i2c
|
||||
- enum:
|
||||
- amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
|
||||
- amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
|
||||
- amlogic,meson-axg-i2c # AXG and compatible SoCs
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -22,7 +22,9 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: apple,t6020-i2c
|
||||
- enum:
|
||||
- apple,t6020-i2c
|
||||
- apple,t8122-i2c
|
||||
- const: apple,t8103-i2c
|
||||
- items:
|
||||
- enum:
|
||||
|
|
|
|||
49
Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
Normal file
49
Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/cnxt,cx92755-i2c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Conexant Digicolor I2C controller
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
maintainers:
|
||||
- Baruch Siach <baruch@tkos.co.il>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: cnxt,cx92755-i2c
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-frequency:
|
||||
default: 100000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c@f0000120 {
|
||||
compatible = "cnxt,cx92755-i2c";
|
||||
reg = <0xf0000120 0x10>;
|
||||
interrupts = <28>;
|
||||
clocks = <&main_clk>;
|
||||
clock-frequency = <100000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
Conexant Digicolor I2C controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "cnxt,cx92755-i2c"
|
||||
- reg: physical address and length of the device registers
|
||||
- interrupts: a single interrupt specifier
|
||||
- clocks: clock for the device
|
||||
- #address-cells: should be <1>
|
||||
- #size-cells: should be <0>
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: the desired I2C bus clock frequency in Hz; in
|
||||
absence of this property the default value is used (100 kHz).
|
||||
|
||||
Example:
|
||||
|
||||
i2c: i2c@f0000120 {
|
||||
compatible = "cnxt,cx92755-i2c";
|
||||
reg = <0xf0000120 0x10>;
|
||||
interrupts = <28>;
|
||||
clocks = <&main_clk>;
|
||||
clock-frequency = <100000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -4,20 +4,23 @@
|
|||
$id: http://devicetree.org/schemas/iio/accel/adi,adxl372.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
|
||||
title: Analog Devices ADXL371/ADXL372 3-Axis, +/-(200g) Digital Accelerometer
|
||||
|
||||
maintainers:
|
||||
- Marcelo Schmitt <marcelo.schmitt@analog.com>
|
||||
- Nuno Sá <nuno.sa@analog.com>
|
||||
- Antoniu Miclaus <antoniu.miclaus@analog.com>
|
||||
|
||||
description: |
|
||||
Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer that supports
|
||||
both I2C & SPI interfaces
|
||||
Analog Devices ADXL371/ADXL372 3-Axis, +/-(200g) Digital Accelerometer that
|
||||
supports both I2C & SPI interfaces
|
||||
https://www.analog.com/en/products/adxl371.html
|
||||
https://www.analog.com/en/products/adxl372.html
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,adxl371
|
||||
- adi,adxl372
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -16,25 +16,27 @@ description:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
# bmc150-accel driver in Linux
|
||||
- bosch,bma222
|
||||
- bosch,bma222e
|
||||
- bosch,bma250e
|
||||
- bosch,bma253
|
||||
- bosch,bma254
|
||||
- bosch,bma255
|
||||
- bosch,bma280
|
||||
- bosch,bmc150_accel
|
||||
- bosch,bmc156_accel
|
||||
- bosch,bmi055_accel
|
||||
oneOf:
|
||||
- enum:
|
||||
- bosch,bma222
|
||||
- bosch,bma222e
|
||||
- bosch,bma250e
|
||||
- bosch,bma253
|
||||
- bosch,bma254
|
||||
- bosch,bma255
|
||||
- bosch,bma280
|
||||
- bosch,bmc150_accel
|
||||
- bosch,bmc156_accel
|
||||
- bosch,bmi055_accel
|
||||
|
||||
# bma180 driver in Linux
|
||||
- bosch,bma023
|
||||
- bosch,bma150
|
||||
- bosch,bma180
|
||||
- bosch,bma250
|
||||
- bosch,smb380
|
||||
- bosch,bma023
|
||||
- bosch,bma150
|
||||
- bosch,bma180
|
||||
- bosch,bma250
|
||||
- bosch,smb380
|
||||
- items:
|
||||
- const: bosch,bmx055-accel
|
||||
- const: bosch,bmc150_accel
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -19,6 +19,10 @@ description: |
|
|||
* https://www.analog.com/media/en/technical-documentation/data-sheets/ad4030-24-4032-24.pdf
|
||||
* https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-24_ad4632-24.pdf
|
||||
* https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-16-4632-16.pdf
|
||||
* https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4216.pdf
|
||||
* https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4224.pdf
|
||||
|
||||
$ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -29,6 +33,8 @@ properties:
|
|||
- adi,ad4630-24
|
||||
- adi,ad4632-16
|
||||
- adi,ad4632-24
|
||||
- adi,adaq4216
|
||||
- adi,adaq4224
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -60,6 +66,14 @@ properties:
|
|||
description:
|
||||
Internal buffered Reference. Used when ref-supply is not connected.
|
||||
|
||||
vddh-supply:
|
||||
description:
|
||||
PGIA Positive Power Supply.
|
||||
|
||||
vdd-fda-supply:
|
||||
description:
|
||||
FDA Positive Power Supply.
|
||||
|
||||
cnv-gpios:
|
||||
description:
|
||||
The Convert Input (CNV). It initiates the sampling conversions.
|
||||
|
|
@ -70,6 +84,17 @@ properties:
|
|||
The Reset Input (/RST). Used for asynchronous device reset.
|
||||
maxItems: 1
|
||||
|
||||
pga-gpios:
|
||||
description:
|
||||
A0 and A1 pins for gain selection. For devices that have PGA configuration
|
||||
input pins, pga-gpios should be defined.
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
pwms:
|
||||
description: PWM signal connected to the CNV pin.
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
description:
|
||||
The BUSY pin is used to signal that the conversions results are available
|
||||
|
|
@ -107,6 +132,22 @@ allOf:
|
|||
properties:
|
||||
spi-rx-bus-width:
|
||||
maxItems: 1
|
||||
# ADAQ devices require a gain property to indicate how hardware PGA is set
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
pattern: ^adi,adaq
|
||||
then:
|
||||
required:
|
||||
- vddh-supply
|
||||
- vdd-fda-supply
|
||||
- pga-gpios
|
||||
properties:
|
||||
ref-supply: false
|
||||
else:
|
||||
properties:
|
||||
pga-gpios: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
@ -148,3 +189,26 @@ examples:
|
|||
reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@0 {
|
||||
compatible = "adi,adaq4216";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <80000000>;
|
||||
vdd-5v-supply = <&supply_5V>;
|
||||
vdd-1v8-supply = <&supply_1_8V>;
|
||||
vio-supply = <&supply_1_8V>;
|
||||
refin-supply = <&refin_sup>;
|
||||
vddh-supply = <&vddh>;
|
||||
vdd-fda-supply = <&vdd_fda>;
|
||||
cnv-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
|
||||
pga-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>,
|
||||
<&gpio0 3 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -27,10 +27,13 @@ properties:
|
|||
enum:
|
||||
- adi,ad4080
|
||||
- adi,ad4081
|
||||
- adi,ad4082
|
||||
- adi,ad4083
|
||||
- adi,ad4084
|
||||
- adi,ad4085
|
||||
- adi,ad4086
|
||||
- adi,ad4087
|
||||
- adi,ad4088
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -62,6 +62,11 @@ properties:
|
|||
spi-cpol: true
|
||||
spi-cpha: true
|
||||
|
||||
spi-rx-bus-width:
|
||||
maxItems: 4
|
||||
items:
|
||||
maximum: 1
|
||||
|
||||
vcc-supply:
|
||||
description: A 3V to 3.6V supply that powers the chip.
|
||||
|
||||
|
|
@ -160,6 +165,23 @@ patternProperties:
|
|||
unevaluatedProperties: false
|
||||
|
||||
allOf:
|
||||
# 2-channel chips only have two SDO lines
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,ad7380
|
||||
- adi,ad7381
|
||||
- adi,ad7383
|
||||
- adi,ad7384
|
||||
- adi,ad7386
|
||||
- adi,ad7387
|
||||
- adi,ad7388
|
||||
then:
|
||||
properties:
|
||||
spi-rx-bus-width:
|
||||
maxItems: 2
|
||||
|
||||
# pseudo-differential chips require common mode voltage supplies,
|
||||
# true differential chips don't use them
|
||||
- if:
|
||||
|
|
@ -284,6 +306,7 @@ examples:
|
|||
spi-cpol;
|
||||
spi-cpha;
|
||||
spi-max-frequency = <80000000>;
|
||||
spi-rx-bus-width = <1>, <1>, <1>, <1>;
|
||||
|
||||
interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
|
||||
interrupt-parent = <&gpio0>;
|
||||
|
|
|
|||
|
|
@ -27,7 +27,11 @@ properties:
|
|||
- amlogic,meson-gxm-saradc
|
||||
- amlogic,meson-axg-saradc
|
||||
- amlogic,meson-g12a-saradc
|
||||
# Usage of this generic fallback is not allowed for new devices
|
||||
- const: amlogic,meson-saradc
|
||||
- items:
|
||||
- const: amlogic,meson-s4-saradc
|
||||
- const: amlogic,meson-g12a-saradc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -11,6 +11,12 @@ maintainers:
|
|||
- Liam Beguin <liambeguin@gmail.com>
|
||||
|
||||
description: |
|
||||
LTC2305:
|
||||
low noise, low power, 2-channel, 12-bit successive approximation ADC with an
|
||||
I2C compatible serial interface.
|
||||
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/23015fb.pdf
|
||||
|
||||
LTC2309:
|
||||
low noise, low power, 8-channel, 12-bit successive approximation ADC with an
|
||||
I2C compatible serial interface.
|
||||
|
|
@ -28,6 +34,7 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- lltc,ltc2305
|
||||
- lltc,ltc2309
|
||||
- lltc,ltc2497
|
||||
- lltc,ltc2499
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ properties:
|
|||
enum:
|
||||
- motorola,cpcap-adc
|
||||
- motorola,mapphone-cpcap-adc
|
||||
- motorola,mot-cpcap-adc
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -0,0 +1,151 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/qcom,spmi-adc5-gen3.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm's SPMI PMIC ADC5 Gen3
|
||||
|
||||
maintainers:
|
||||
- Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
|
||||
|
||||
description: |
|
||||
SPMI PMIC5 Gen3 voltage ADC (ADC) provides interface to clients to read
|
||||
voltage. It is a 16-bit sigma-delta ADC. It also performs the same thermal
|
||||
monitoring function as the existing ADC_TM devices.
|
||||
|
||||
The interface is implemented on SDAM (Shared Direct Access Memory) peripherals
|
||||
on the master PMIC rather than a dedicated ADC peripheral. The number of PMIC
|
||||
SDAM peripherals allocated for ADC is not correlated with the PMIC used, it is
|
||||
programmed in FW (PBS) and is fixed per SOC, based on the SOC requirements.
|
||||
All boards using a particular (SOC + master PMIC) combination will have the
|
||||
same number of ADC SDAMs supported on that PMIC.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,spmi-adc5-gen3
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: SDAM0 base address in the SPMI PMIC register map
|
||||
- description: SDAM1 base address
|
||||
minItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
"#io-channel-cells":
|
||||
const: 1
|
||||
|
||||
"#thermal-sensor-cells":
|
||||
const: 1
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: SDAM0 end of conversion (EOC) interrupt
|
||||
- description: SDAM1 EOC interrupt
|
||||
minItems: 1
|
||||
|
||||
patternProperties:
|
||||
"^channel@[0-9a-f]+$":
|
||||
type: object
|
||||
unevaluatedProperties: false
|
||||
$ref: /schemas/iio/adc/qcom,spmi-vadc-common.yaml
|
||||
description:
|
||||
Represents the external channels which are connected to the ADC.
|
||||
|
||||
properties:
|
||||
qcom,decimation:
|
||||
enum: [ 85, 340, 1360 ]
|
||||
default: 1360
|
||||
|
||||
qcom,hw-settle-time:
|
||||
enum: [ 15, 100, 200, 300, 400, 500, 600, 700,
|
||||
1000, 2000, 4000, 8000, 16000, 32000, 64000, 128000 ]
|
||||
default: 15
|
||||
|
||||
qcom,avg-samples:
|
||||
enum: [ 1, 2, 4, 8, 16 ]
|
||||
default: 1
|
||||
|
||||
qcom,adc-tm:
|
||||
description:
|
||||
ADC_TM is a threshold monitoring feature in HW which can be enabled
|
||||
on any ADC channel, to trigger an IRQ for threshold violation. In
|
||||
earlier ADC generations, it was implemented in a separate device
|
||||
(documented in Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml.)
|
||||
In Gen3, this feature can be enabled in the same ADC device for any
|
||||
channel and threshold monitoring and IRQ triggering are handled in FW
|
||||
(PBS) instead of another dedicated HW block.
|
||||
This property indicates ADC_TM monitoring is done on this channel.
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- "#io-channel-cells"
|
||||
- interrupts
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
pmic {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@9000 {
|
||||
compatible = "qcom,spmi-adc5-gen3";
|
||||
reg = <0x9000>, <0x9100>;
|
||||
interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
|
||||
<0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#io-channel-cells = <1>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
|
||||
/* PMK8550 Channel nodes */
|
||||
channel@3 {
|
||||
reg = <0x3>;
|
||||
label = "pmk8550_die_temp";
|
||||
qcom,pre-scaling = <1 1>;
|
||||
};
|
||||
|
||||
channel@44 {
|
||||
reg = <0x44>;
|
||||
label = "pmk8550_xo_therm";
|
||||
qcom,pre-scaling = <1 1>;
|
||||
qcom,ratiometric;
|
||||
qcom,hw-settle-time = <200>;
|
||||
qcom,adc-tm;
|
||||
};
|
||||
|
||||
/* PM8550 Channel nodes */
|
||||
channel@103 {
|
||||
reg = <0x103>;
|
||||
label = "pm8550_die_temp";
|
||||
qcom,pre-scaling = <1 1>;
|
||||
};
|
||||
|
||||
/* PM8550B Channel nodes */
|
||||
channel@78f {
|
||||
reg = <0x78f>;
|
||||
label = "pm8550b_vbat_sns_qbg";
|
||||
qcom,pre-scaling = <1 3>;
|
||||
};
|
||||
|
||||
/* PM8550VS_C Channel nodes */
|
||||
channel@203 {
|
||||
reg = <0x203>;
|
||||
label = "pm8550vs_c_die_temp";
|
||||
qcom,pre-scaling = <1 1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/qcom,spmi-vadc-common.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Technologies, Inc. SPMI PMIC ADC channels
|
||||
|
||||
maintainers:
|
||||
- Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
|
||||
|
||||
description:
|
||||
This defines the common properties used to define Qualcomm VADC channels.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
description:
|
||||
ADC channel number (PMIC-specific for versions after PMIC5 ADC).
|
||||
maxItems: 1
|
||||
|
||||
label:
|
||||
description:
|
||||
ADC input of the platform as seen in the schematics.
|
||||
For thermistor inputs connected to generic AMUX or GPIO inputs
|
||||
these can vary across platform for the same pins. Hence select
|
||||
the platform schematics name for this channel.
|
||||
|
||||
qcom,decimation:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
This parameter is used to decrease ADC sampling rate.
|
||||
Quicker measurements can be made by reducing decimation ratio.
|
||||
|
||||
qcom,pre-scaling:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
description:
|
||||
Used for scaling the channel input signal before the signal is
|
||||
fed to VADC. The configuration for this node is to know the
|
||||
pre-determined ratio and use it for post scaling. It is a pair of
|
||||
integers, denoting the numerator and denominator of the fraction by which
|
||||
input signal is multiplied. For example, <1 3> indicates the signal is scaled
|
||||
down to 1/3 of its value before ADC measurement.
|
||||
If property is not found default value depending on chip will be used.
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- enum: [ 1, 3, 4, 6, 20, 8, 10, 16 ]
|
||||
- items:
|
||||
- const: 10
|
||||
- const: 81
|
||||
|
||||
qcom,ratiometric:
|
||||
type: boolean
|
||||
description: |
|
||||
Channel calibration type.
|
||||
- For compatible property "qcom,spmi-vadc", if this property is
|
||||
specified VADC will use the VDD reference (1.8V) and GND for
|
||||
channel calibration. If property is not found, channel will be
|
||||
calibrated with 0.625V and 1.25V reference channels, also
|
||||
known as absolute calibration.
|
||||
- For other compatible properties, if this property is specified
|
||||
VADC will use the VDD reference (1.875V) and GND for channel
|
||||
calibration. If property is not found, channel will be calibrated
|
||||
with 0V and 1.25V reference channels, also known as absolute calibration.
|
||||
|
||||
qcom,hw-settle-time:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Time between AMUX getting configured and the ADC starting
|
||||
conversion. The 'hw_settle_time' is an index used from valid values
|
||||
and programmed in hardware to achieve the hardware settling delay.
|
||||
|
||||
qcom,avg-samples:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Number of samples to be used for measurement.
|
||||
Averaging provides the option to obtain a single measurement
|
||||
from the ADC that is an average of multiple samples. The value
|
||||
selected is 2^(value).
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: true
|
||||
|
|
@ -15,6 +15,8 @@ description: |
|
|||
voltage. The VADC is a 15-bit sigma-delta ADC.
|
||||
SPMI PMIC5/PMIC7 voltage ADC (ADC) provides interface to clients to read
|
||||
voltage. The VADC is a 16-bit sigma-delta ADC.
|
||||
Note that PMIC7 ADC is the generation between PMIC5 and PMIC5 Gen3 ADC,
|
||||
it can be considered like PMIC5 Gen2.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -56,7 +58,7 @@ required:
|
|||
patternProperties:
|
||||
"^channel@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
description: |
|
||||
Represents the external channels which are connected to the ADC.
|
||||
For compatible property "qcom,spmi-vadc" following channels, also known as
|
||||
|
|
@ -64,79 +66,7 @@ patternProperties:
|
|||
configuration nodes should be defined:
|
||||
VADC_REF_625MV and/or VADC_SPARE1(based on PMIC version) VADC_REF_1250MV,
|
||||
VADC_GND_REF and VADC_VDD_VADC.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: |
|
||||
ADC channel number.
|
||||
See include/dt-bindings/iio/qcom,spmi-vadc.h
|
||||
For PMIC7 ADC, the channel numbers are specified separately per PMIC
|
||||
in the PMIC-specific files in include/dt-bindings/iio/.
|
||||
|
||||
label:
|
||||
description: |
|
||||
ADC input of the platform as seen in the schematics.
|
||||
For thermistor inputs connected to generic AMUX or GPIO inputs
|
||||
these can vary across platform for the same pins. Hence select
|
||||
the platform schematics name for this channel.
|
||||
|
||||
qcom,decimation:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
This parameter is used to decrease ADC sampling rate.
|
||||
Quicker measurements can be made by reducing decimation ratio.
|
||||
|
||||
qcom,pre-scaling:
|
||||
description: |
|
||||
Used for scaling the channel input signal before the signal is
|
||||
fed to VADC. The configuration for this node is to know the
|
||||
pre-determined ratio and use it for post scaling. It is a pair of
|
||||
integers, denoting the numerator and denominator of the fraction by which
|
||||
input signal is multiplied. For example, <1 3> indicates the signal is scaled
|
||||
down to 1/3 of its value before ADC measurement.
|
||||
If property is not found default value depending on chip will be used.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- enum: [ 1, 3, 4, 6, 20, 8, 10, 16 ]
|
||||
- items:
|
||||
- const: 10
|
||||
- const: 81
|
||||
|
||||
qcom,ratiometric:
|
||||
description: |
|
||||
Channel calibration type.
|
||||
- For compatible property "qcom,spmi-vadc", if this property is
|
||||
specified VADC will use the VDD reference (1.8V) and GND for
|
||||
channel calibration. If property is not found, channel will be
|
||||
calibrated with 0.625V and 1.25V reference channels, also
|
||||
known as absolute calibration.
|
||||
- For compatible property "qcom,spmi-adc5", "qcom,spmi-adc7" and
|
||||
"qcom,spmi-adc-rev2", if this property is specified VADC will use
|
||||
the VDD reference (1.875V) and GND for channel calibration. If
|
||||
property is not found, channel will be calibrated with 0V and 1.25V
|
||||
reference channels, also known as absolute calibration.
|
||||
type: boolean
|
||||
|
||||
qcom,hw-settle-time:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Time between AMUX getting configured and the ADC starting
|
||||
conversion. The 'hw_settle_time' is an index used from valid values
|
||||
and programmed in hardware to achieve the hardware settling delay.
|
||||
|
||||
qcom,avg-samples:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Number of samples to be used for measurement.
|
||||
Averaging provides the option to obtain a single measurement
|
||||
from the ADC that is an average of multiple samples. The value
|
||||
selected is 2^(value).
|
||||
|
||||
required:
|
||||
- reg
|
||||
$ref: /schemas/iio/adc/qcom,spmi-vadc-common.yaml
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
|
|
|
|||
101
Documentation/devicetree/bindings/iio/amplifiers/adi,ad8366.yaml
Normal file
101
Documentation/devicetree/bindings/iio/amplifiers/adi,ad8366.yaml
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/amplifiers/adi,ad8366.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: AD8366 and similar Gain Amplifiers and Digital Attenuators
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
- Rodrigo Alencar <rodrigo.alencar@analog.com>
|
||||
|
||||
description:
|
||||
Digital Variable Gain Amplifiers (VGAs) and Digital Attenuators with
|
||||
SPI interface.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,ad8366
|
||||
- adi,ada4961
|
||||
- adi,adl5240
|
||||
- adi,adrf5702
|
||||
- adi,adrf5703
|
||||
- adi,adrf5720
|
||||
- adi,adrf5730
|
||||
- adi,adrf5731
|
||||
- adi,hmc271a
|
||||
- adi,hmc792a
|
||||
- adi,hmc1018a
|
||||
- adi,hmc1019a
|
||||
- adi,hmc1119
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vcc-supply:
|
||||
description: Regulator that provides power to the device.
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
description: Power-up or Serial Mode Enable GPIO.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- vcc-supply
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: adi,hmc271a
|
||||
then:
|
||||
properties:
|
||||
reset-gpios: false
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
anyOf:
|
||||
- const: adi,ad8366
|
||||
- const: adi,ada4961
|
||||
- const: adi,adrf5702
|
||||
- const: adi,adrf5703
|
||||
- const: adi,adrf5720
|
||||
- const: adi,adrf5730
|
||||
- const: adi,adrf5731
|
||||
- const: adi,hmc792a
|
||||
- const: adi,hmc1018a
|
||||
- const: adi,hmc1019a
|
||||
- const: adi,hmc1119
|
||||
then:
|
||||
properties:
|
||||
enable-gpios: false
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
amplifier@0 {
|
||||
compatible = "adi,ad8366";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1000000>;
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
enable-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -4,36 +4,49 @@
|
|||
$id: http://devicetree.org/schemas/iio/dac/lltc,ltc2632.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Linear Technology LTC263x 12-/10-/8-Bit Rail-to-Rail DAC
|
||||
title: Linear Technology LTC263x and LTC2654 Rail-to-Rail DAC
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
|
||||
description: |
|
||||
Bindings for the Linear Technology LTC2632/2634/2636 DAC
|
||||
Datasheet can be found here: https://www.analog.com/media/en/technical-documentation/data-sheets/LTC263[246].pdf
|
||||
Bindings for the Linear Technology LTC2632/2634/2636/2654 DAC
|
||||
Datasheet can be found here:
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/LTC263[246].pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2654f.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- lltc,ltc2632-l12
|
||||
- lltc,ltc2632-l10
|
||||
- lltc,ltc2632-l8
|
||||
- lltc,ltc2632-h12
|
||||
- lltc,ltc2632-h10
|
||||
- lltc,ltc2632-h8
|
||||
- lltc,ltc2634-l12
|
||||
- lltc,ltc2634-l10
|
||||
- lltc,ltc2634-l8
|
||||
- lltc,ltc2634-h12
|
||||
- lltc,ltc2634-h10
|
||||
- lltc,ltc2634-h8
|
||||
- lltc,ltc2636-l12
|
||||
- lltc,ltc2636-l10
|
||||
- lltc,ltc2636-l8
|
||||
- lltc,ltc2636-h12
|
||||
- lltc,ltc2636-h10
|
||||
- lltc,ltc2636-h8
|
||||
oneOf:
|
||||
- enum:
|
||||
- lltc,ltc2632-l12
|
||||
- lltc,ltc2632-l10
|
||||
- lltc,ltc2632-l8
|
||||
- lltc,ltc2632-h12
|
||||
- lltc,ltc2632-h10
|
||||
- lltc,ltc2632-h8
|
||||
- lltc,ltc2634-l12
|
||||
- lltc,ltc2634-l10
|
||||
- lltc,ltc2634-l8
|
||||
- lltc,ltc2634-h12
|
||||
- lltc,ltc2634-h10
|
||||
- lltc,ltc2634-h8
|
||||
- lltc,ltc2636-l12
|
||||
- lltc,ltc2636-l10
|
||||
- lltc,ltc2636-l8
|
||||
- lltc,ltc2636-h12
|
||||
- lltc,ltc2636-h10
|
||||
- lltc,ltc2636-h8
|
||||
- lltc,ltc2654-l16
|
||||
- lltc,ltc2654-h16
|
||||
- items:
|
||||
- enum:
|
||||
- lltc,ltc2654-l12
|
||||
- const: lltc,ltc2634-l12
|
||||
- items:
|
||||
- enum:
|
||||
- lltc,ltc2654-h12
|
||||
- const: lltc,ltc2634-h12
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -4,18 +4,21 @@
|
|||
$id: http://devicetree.org/schemas/iio/dac/maxim,ds4424.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim Integrated DS4422/DS4424 7-bit Sink/Source Current DAC
|
||||
title: Maxim Integrated DS4402/DS4404 and DS4422/DS4424 Current DACs
|
||||
|
||||
maintainers:
|
||||
- Ismail Kose <ihkose@gmail.com>
|
||||
|
||||
description: |
|
||||
Datasheet publicly available at:
|
||||
Datasheets publicly available at:
|
||||
https://datasheets.maximintegrated.com/en/ds/DS4402-DS4404.pdf
|
||||
https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- maxim,ds4402
|
||||
- maxim,ds4404
|
||||
- maxim,ds4422
|
||||
- maxim,ds4424
|
||||
|
||||
|
|
@ -24,9 +27,43 @@ properties:
|
|||
|
||||
vcc-supply: true
|
||||
|
||||
maxim,rfs-ohms:
|
||||
description: |
|
||||
Array of resistance values in Ohms for the external Rfs resistors
|
||||
connected to the FS pins. These values determine the full-scale
|
||||
output current. The actual resistance depends on the chip variant
|
||||
and specific hardware design requirements.
|
||||
minItems: 2
|
||||
maxItems: 4
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- maxim,rfs-ohms
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- maxim,ds4402
|
||||
- maxim,ds4422
|
||||
then:
|
||||
properties:
|
||||
maxim,rfs-ohms:
|
||||
maxItems: 2
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- maxim,ds4404
|
||||
- maxim,ds4424
|
||||
then:
|
||||
properties:
|
||||
maxim,rfs-ohms:
|
||||
minItems: 4
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
@ -40,6 +77,7 @@ examples:
|
|||
compatible = "maxim,ds4424";
|
||||
reg = <0x10>; /* When A0, A1 pins are ground */
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
maxim,rfs-ohms = <40000>, <40000>, <40000>, <40000>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ title: Texas Instruments DAC7612 family of DACs
|
|||
description:
|
||||
The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with
|
||||
guaranteed 12-bit monotonicity performance over the industrial temperature
|
||||
range. Is is programmable through an SPI interface.
|
||||
range. It is programmable through an SPI interface.
|
||||
|
||||
maintainers:
|
||||
- Ricardo Ribalda Delgado <ricardo@ribalda.com>
|
||||
|
|
|
|||
|
|
@ -11,10 +11,14 @@ maintainers:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- bosch,bmg160
|
||||
- bosch,bmi055_gyro
|
||||
- bosch,bmi088_gyro
|
||||
oneOf:
|
||||
- enum:
|
||||
- bosch,bmg160
|
||||
- bosch,bmi055_gyro
|
||||
- bosch,bmi088_gyro
|
||||
- items:
|
||||
- const: bosch,bmx055-gyro
|
||||
- const: bosch,bmg160
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -18,16 +18,32 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- vishay,vcnl4000
|
||||
- vishay,vcnl4010
|
||||
- vishay,vcnl4020
|
||||
- vishay,vcnl4040
|
||||
- vishay,vcnl4200
|
||||
oneOf:
|
||||
- enum:
|
||||
- capella,cm36672p
|
||||
- vishay,vcnl4000
|
||||
- vishay,vcnl4010
|
||||
- vishay,vcnl4020
|
||||
- vishay,vcnl4040
|
||||
- vishay,vcnl4200
|
||||
- items:
|
||||
- const: capella,cm36686
|
||||
- const: vishay,vcnl4040
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply:
|
||||
description: Regulator providing power to the "VDD" pin.
|
||||
|
||||
vio-supply:
|
||||
description: Regulator providing power for pull-up of the I/O lines.
|
||||
Does not connect to the sensor directly, but is needed for the
|
||||
correct operation of the I2C and interrupt lines.
|
||||
|
||||
vled-supply:
|
||||
description: Regulator providing power to the IR anode pin.
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
|
|
@ -49,6 +65,9 @@ examples:
|
|||
compatible = "vishay,vcnl4200";
|
||||
reg = <0x51>;
|
||||
proximity-near-level = <220>;
|
||||
vdd-supply = <®_vdd>;
|
||||
vio-supply = <®_vio>;
|
||||
vled-supply = <®_vled>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
|||
|
|
@ -21,11 +21,15 @@ properties:
|
|||
description:
|
||||
Note the bmm150_magn is a deprecated compatible as this part contains only
|
||||
a magnetometer.
|
||||
enum:
|
||||
- bosch,bmc150_magn
|
||||
- bosch,bmc156_magn
|
||||
- bosch,bmm150
|
||||
- bosch,bmm150_magn
|
||||
oneOf:
|
||||
- enum:
|
||||
- bosch,bmc150_magn
|
||||
- bosch,bmc156_magn
|
||||
- bosch,bmm150
|
||||
- bosch,bmm150_magn
|
||||
- items:
|
||||
- const: bosch,bmx055-magn
|
||||
- const: bosch,bmc150_magn
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -4,14 +4,17 @@
|
|||
$id: http://devicetree.org/schemas/iio/proximity/st,vl53l0x.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ST VL53L0X ToF ranging sensor
|
||||
title: ST VL53L0X/VL53L1X ToF ranging sensor
|
||||
|
||||
maintainers:
|
||||
- Song Qiang <songqiang1304521@gmail.com>
|
||||
- Siratul Islam <email@sirat.me>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: st,vl53l0x
|
||||
enum:
|
||||
- st,vl53l0x
|
||||
- st,vl53l1x
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -21,6 +24,8 @@ properties:
|
|||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description:
|
||||
Phandle to the XSHUT GPIO. Used for hardware reset.
|
||||
|
||||
vdd-supply: true
|
||||
|
||||
|
|
@ -28,6 +33,16 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,vl53l1x
|
||||
then:
|
||||
required:
|
||||
- vdd-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
@ -38,8 +53,9 @@ examples:
|
|||
#size-cells = <0>;
|
||||
|
||||
proximity@29 {
|
||||
compatible = "st,vl53l0x";
|
||||
compatible = "st,vl53l1x";
|
||||
reg = <0x29>;
|
||||
vdd-supply = <®_3v3>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -28,6 +28,9 @@ properties:
|
|||
|
||||
vdd-supply: true
|
||||
|
||||
firmware-name:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
|
|
@ -65,6 +68,7 @@ examples:
|
|||
interrupt-parent = <&pio>;
|
||||
interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
|
||||
vdd-supply = <&pp1800_prox>;
|
||||
firmware-name = "hx9023s.bin";
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -11,7 +11,12 @@ maintainers:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: awinic,aw86927
|
||||
oneOf:
|
||||
- const: awinic,aw86927
|
||||
- items:
|
||||
- enum:
|
||||
- awinic,aw86938
|
||||
- const: awinic,aw86927
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ maintainers:
|
|||
- Alexander Sverdlin <alexander.sverdlin@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
description:
|
||||
|
|
@ -37,10 +38,8 @@ properties:
|
|||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
debounce-delay-ms:
|
||||
description: |
|
||||
Time in microseconds that key must be pressed or
|
||||
released for state change interrupt to trigger.
|
||||
# Time for state change interrupt to trigger
|
||||
debounce-delay-ms: true
|
||||
|
||||
cirrus,prescale:
|
||||
description: row/column counter pre-scaler load value
|
||||
|
|
|
|||
|
|
@ -0,0 +1,108 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: GPIO charlieplex keypad
|
||||
|
||||
maintainers:
|
||||
- Hugo Villeneuve <hvilleneuve@dimonoff.com>
|
||||
|
||||
description: |
|
||||
The charlieplex keypad supports N^2)-N different key combinations (where N is
|
||||
the number of I/O lines). Key presses and releases are detected by configuring
|
||||
only one line as output at a time, and reading other line states. This process
|
||||
is repeated for each line. Diodes are required to ensure current flows in only
|
||||
one direction between any pair of pins, as well as pull-up or pull-down
|
||||
resistors on all I/O lines.
|
||||
This mechanism doesn't allow to detect simultaneous key presses.
|
||||
|
||||
Wiring example for 3 lines keyboard with 6 switches and 3 diodes (pull-up/down
|
||||
resistors not shown but needed on L0, L1 and L2):
|
||||
|
||||
L0 --+---------------------+----------------------+
|
||||
| | |
|
||||
L1 -------+-----------+---------------------+ |
|
||||
| | | | | |
|
||||
L2 -------------+----------------+-----+ | |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| S1 \ S2 \ | S3 \ S4 \ | S5 \ S6 \
|
||||
| | | | | | | | |
|
||||
| +--+--+ | +--+--+ | +--+--+
|
||||
| | | | | |
|
||||
| D1 v | D2 v | D3 v
|
||||
| - (k) | - (k) | - (k)
|
||||
| | | | | |
|
||||
+-------+ +-------+ +-------+
|
||||
|
||||
L: GPIO line
|
||||
S: switch
|
||||
D: diode (k indicates cathode)
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: gpio-charlieplex-keypad
|
||||
|
||||
autorepeat: true
|
||||
|
||||
debounce-delay-ms:
|
||||
default: 5
|
||||
|
||||
line-gpios:
|
||||
description:
|
||||
List of GPIOs used as lines. The gpio specifier for this property
|
||||
depends on the gpio controller to which these lines are connected.
|
||||
|
||||
linux,keymap: true
|
||||
|
||||
poll-interval: true
|
||||
|
||||
settling-time-us: true
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- line-gpios
|
||||
- linux,keymap
|
||||
- poll-interval
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/input/input.h>
|
||||
|
||||
keyboard {
|
||||
compatible = "gpio-charlieplex-keypad";
|
||||
debounce-delay-ms = <20>;
|
||||
poll-interval = <5>;
|
||||
settling-time-us = <2>;
|
||||
|
||||
line-gpios = <&gpio2 25 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)
|
||||
&gpio2 26 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)
|
||||
&gpio2 27 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
|
||||
|
||||
/* MATRIX_KEY(output, input, key-code) */
|
||||
linux,keymap = <
|
||||
/*
|
||||
* According to wiring diagram above, if L1 is configured as
|
||||
* output and HIGH, and we detect a HIGH level on input L0,
|
||||
* then it means S1 is pressed: MATRIX_KEY(L1, L0, KEY...)
|
||||
*/
|
||||
MATRIX_KEY(1, 0, KEY_F1) /* S1 */
|
||||
MATRIX_KEY(2, 0, KEY_F2) /* S2 */
|
||||
MATRIX_KEY(0, 1, KEY_F3) /* S3 */
|
||||
MATRIX_KEY(2, 1, KEY_F4) /* S4 */
|
||||
MATRIX_KEY(1, 2, KEY_F5) /* S5 */
|
||||
MATRIX_KEY(0, 2, KEY_F6) /* S6 */
|
||||
>;
|
||||
};
|
||||
|
|
@ -18,6 +18,7 @@ description:
|
|||
report the event using GPIO interrupts to the cpu.
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
properties:
|
||||
|
|
@ -46,9 +47,7 @@ properties:
|
|||
Force GPIO polarity to active low.
|
||||
In the absence of this property GPIOs are treated as active high.
|
||||
|
||||
debounce-delay-ms:
|
||||
description: Debounce interval in milliseconds.
|
||||
default: 0
|
||||
debounce-delay-ms: true
|
||||
|
||||
col-scan-delay-us:
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -14,6 +14,14 @@ properties:
|
|||
description: Enable autorepeat when key is pressed and held down.
|
||||
type: boolean
|
||||
|
||||
debounce-delay-ms:
|
||||
description:
|
||||
Debounce delay in milliseconds. This is the time during which the key
|
||||
press or release signal must remain stable before it is considered valid.
|
||||
minimum: 0
|
||||
maximum: 999
|
||||
default: 0
|
||||
|
||||
linux,keycodes:
|
||||
description:
|
||||
Specifies an array of numeric keycode values to be used for reporting
|
||||
|
|
@ -58,6 +66,14 @@ properties:
|
|||
reset automatically. Device with key pressed reset feature can specify
|
||||
this property.
|
||||
|
||||
settling-time-us:
|
||||
description:
|
||||
Delay, in microseconds, when activating an output line/col/row before
|
||||
we can reliably read other input lines that maybe affected by this
|
||||
output. This can be the case for an output with a RC circuit that affects
|
||||
ramp-up/down times.
|
||||
default: 0
|
||||
|
||||
dependencies:
|
||||
linux,input-type: [ "linux,code" ]
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@
|
|||
$id: http://devicetree.org/schemas/input/matrix-keymap.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Common Key Matrices on Matrix-connected Key Boards
|
||||
title: Common Key Matrices on Matrix-connected Keyboards
|
||||
|
||||
maintainers:
|
||||
- Olof Johansson <olof@lixom.net>
|
||||
|
||||
description: |
|
||||
A simple common binding for matrix-connected key boards. Currently targeted at
|
||||
A simple common binding for matrix-connected keyboards. Currently targeted at
|
||||
defining the keys in the scope of linux key codes since that is a stable and
|
||||
standardized interface at this time.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ maintainers:
|
|||
- Mattijs Korpershoek <mkorpershoek@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
description: |
|
||||
|
|
|
|||
68
Documentation/devicetree/bindings/input/parade,tc3408.yaml
Normal file
68
Documentation/devicetree/bindings/input/parade,tc3408.yaml
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/parade,tc3408.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Parade TC3408 touchscreen controller
|
||||
|
||||
maintainers:
|
||||
- Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
|
||||
|
||||
description: |
|
||||
Parade TC3408 is a touchscreen controller supporting the I2C-HID protocol.
|
||||
It requires a reset GPIO and two power supplies (3.3V and 1.8V).
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/input/touchscreen/touchscreen.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: parade,tc3408
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
vcc33-supply:
|
||||
description: The 3.3V supply to the touchscreen.
|
||||
|
||||
vccio-supply:
|
||||
description: The 1.8V supply to the touchscreen.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- reset-gpios
|
||||
- vcc33-supply
|
||||
- vccio-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
touchscreen: touchscreen@24 {
|
||||
compatible = "parade,tc3408";
|
||||
reg = <0x24>;
|
||||
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
reset-gpios = <&pio 126 GPIO_ACTIVE_LOW>;
|
||||
vcc33-supply = <&pp3300_tchscr_x>;
|
||||
vccio-supply = <&pp1800_tchscr_report_disable>;
|
||||
};
|
||||
};
|
||||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Apple touchscreens attached using the Z2 protocol
|
||||
|
||||
maintainers:
|
||||
- Sasha Finkelstein <fnkl.kernel@gmail.com>
|
||||
- Sasha Finkelstein <k@chaosmail.tech>
|
||||
|
||||
description: A series of touschscreen controllers used in Apple products
|
||||
|
||||
|
|
|
|||
|
|
@ -33,19 +33,23 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- edt,edt-ft5206
|
||||
- edt,edt-ft5306
|
||||
- edt,edt-ft5406
|
||||
- edt,edt-ft5506
|
||||
- evervision,ev-ft5726
|
||||
- focaltech,ft3518
|
||||
- focaltech,ft5426
|
||||
- focaltech,ft5452
|
||||
- focaltech,ft6236
|
||||
- focaltech,ft8201
|
||||
- focaltech,ft8716
|
||||
- focaltech,ft8719
|
||||
oneOf:
|
||||
- enum:
|
||||
- edt,edt-ft5206
|
||||
- edt,edt-ft5306
|
||||
- edt,edt-ft5406
|
||||
- edt,edt-ft5506
|
||||
- evervision,ev-ft5726
|
||||
- focaltech,ft3518
|
||||
- focaltech,ft5426
|
||||
- focaltech,ft5452
|
||||
- focaltech,ft6236
|
||||
- focaltech,ft8201
|
||||
- focaltech,ft8716
|
||||
- focaltech,ft8719
|
||||
- items:
|
||||
- const: focaltech,ft3519
|
||||
- const: focaltech,ft3518
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ properties:
|
|||
description: A phandle to the reset GPIO
|
||||
maxItems: 1
|
||||
|
||||
wakeup-source:
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
@ -51,6 +54,7 @@ examples:
|
|||
reg = <0x55>;
|
||||
interrupts = <2 0>;
|
||||
gpios = <&gpio1 166 0>;
|
||||
wakeup-source;
|
||||
|
||||
touch-overlay {
|
||||
segment-0 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/technologic,ts4800-ts.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TS-4800 Touchscreen
|
||||
|
||||
maintainers:
|
||||
- Eduard Bostina <egbostina@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: technologic,ts4800-ts
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
syscon:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
- items:
|
||||
- description: Phandle to the FPGA's syscon
|
||||
- description: Offset to the touchscreen register
|
||||
- description: Offset to the touchscreen enable bit
|
||||
description: Phandle / integers array that points to the syscon node which
|
||||
describes the FPGA's syscon registers.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- syscon
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
touchscreen@1000 {
|
||||
compatible = "technologic,ts4800-ts";
|
||||
reg = <0x1000 0x100>;
|
||||
syscon = <&fpga_syscon 0x20 3>;
|
||||
};
|
||||
|
|
@ -53,14 +53,14 @@ properties:
|
|||
|
||||
wakeup-source: true
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
* TS-4800 Touchscreen bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "technologic,ts4800-ts"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- syscon: phandle / integers array that points to the syscon node which
|
||||
describes the FPGA's syscon registers.
|
||||
- phandle to FPGA's syscon
|
||||
- offset to the touchscreen register
|
||||
- offset to the touchscreen enable bit
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user