Linux 6.9-rc3

-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmYTAJYeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG2bEH/jOBXd0ZCz+s9+F4
 TbSvDEE8UjitQdEJ5WSBY9CEvFI8OuVQr23gYPUn+gfgqLX0Vsp8HfxL6bBP5Tj6
 DSzAkwF/mvIfa6VLFmO1GmvyhYtmWkmbM825tNqKHSNTBc9cCLH3H+780wNtTMwQ
 VkB8O3KS/wZBGKSbFfiXW+fT3SkWIMLtdBAaox+vcxHXpiluXxSbxANRD5kTbdG0
 UAW9S4+3A0jNk/KeXEvJDqkf7C3ASsjtNPbK+gFDfOXxdNYFTC2IUf93rL61VB4s
 C2rtUklcLE8gFDtvkQ8JtGWmDj4pWPEDIyhICKlzP/aKCjXcNzLaoM0GJQYJS+PN
 aNevw24=
 =318J
 -----END PGP SIGNATURE-----

Merge tag 'v6.9-rc3' into locking/core, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2024-04-09 09:48:09 +02:00
commit d1eec383a8
2420 changed files with 62296 additions and 29692 deletions

1
.gitignore vendored
View File

@ -52,6 +52,7 @@
*.xz
*.zst
Module.symvers
dtbs-list
modules.order
#

View File

@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.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>
Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
@ -36,6 +37,7 @@ Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org>
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com>
Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
@ -110,6 +112,7 @@ Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
@ -340,7 +343,8 @@ Lee Jones <lee@kernel.org> <joneslee@google.com>
Lee Jones <lee@kernel.org> <lee.jones@canonical.com>
Lee Jones <lee@kernel.org> <lee.jones@linaro.org>
Lee Jones <lee@kernel.org> <lee@ubuntu.com>
Leonard Crestez <leonard.crestez@nxp.com> Leonard Crestez <cdleonard@gmail.com>
Leonard Crestez <cdleonard@gmail.com> <leonard.crestez@nxp.com>
Leonard Crestez <cdleonard@gmail.com> <leonard.crestez@intel.com>
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
Leonard Göhrs <l.goehrs@pengutronix.de>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
@ -439,6 +443,8 @@ Mukesh Ojha <quic_mojha@quicinc.com> <mojha@codeaurora.org>
Muna Sinada <quic_msinada@quicinc.com> <msinada@codeaurora.org>
Murali Nalajala <quic_mnalajal@quicinc.com> <mnalajal@codeaurora.org>
Mythri P K <mythripk@ti.com>
Nadav Amit <nadav.amit@gmail.com> <namit@vmware.com>
Nadav Amit <nadav.amit@gmail.com> <namit@cs.technion.ac.il>
Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
Naoya Horiguchi <naoya.horiguchi@nec.com> <n-horiguchi@ah.jp.nec.com>
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
@ -495,7 +501,8 @@ Prasad Sodagudi <quic_psodagud@quicinc.com> <psodagud@codeaurora.org>
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
Qais Yousef <qyousef@layalina.io> <qais.yousef@imgtec.com>
Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
Quentin Monnet <quentin@isovalent.com> <quentin.monnet@netronome.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>
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
@ -525,6 +532,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rjliao@codeaurora.org>
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com>
Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com>
Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
@ -647,6 +655,7 @@ Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com>
Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>

View File

@ -4,6 +4,14 @@ KernelVersion: 3.13
Description: The purpose of this directory is to create and remove it.
A corresponding USB function instance is created/removed.
There are no attributes here.
All parameters are set through FunctionFS.
All attributes are read only:
============= ============================================
ready 1 if the function is ready to be used, E.G.
if userspace has written descriptors and
strings to ep0, so the gadget can be
enabled - 0 otherwise.
============= ============================================
All other parameters are set through FunctionFS.

View File

@ -170,3 +170,90 @@ Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_t
Description:
(RW) Set/Get the MSR(mux select register) for the DSB subunit
TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_mode
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description: (Write) Set the data collection mode of CMB tpdm. Continuous
change creates CMB data set elements on every CMBCLK edge.
Trace-on-change creates CMB data set elements only when a new
data set element differs in value from the previous element
in a CMB data set.
Accepts only one of the 2 values - 0 or 1.
0 : Continuous CMB collection mode.
1 : Trace-on-change CMB collection mode.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpr[0:1]
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the trigger pattern for the CMB
subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpmr[0:1]
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the trigger pattern for the CMB
subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:1]
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the pattern for the CMB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:1]
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern timestamp of CMB tpdm. Read
the pattern timestamp of CMB tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Disable CMB pattern timestamp.
1 : Enable CMB pattern timestamp.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger timestamp of the CMB for tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Set the CMB trigger type to false
1 : Set the CMB trigger type to true
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Read or write the status of timestamp upon all interface.
Only value 0 and 1 can be written to this node. Set this node to 1 to requeset
timestamp to all trace packet.
Accepts only one of the 2 values - 0 or 1.
0 : Disable the timestamp of all trace packets.
1 : Enable the timestamp of all trace packets.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
Date: January 2024
KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the MSR(mux select register) for the CMB subunit
TPDM.

View File

@ -0,0 +1,9 @@
What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistorY
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
The value of the shunt resistor may be known only at runtime
and set by a client application. This attribute allows to
set its value in micro-ohms. X is the IIO index of the device.
Y is the channel number. The value is used to calculate
current, power and accumulated energy.

View File

@ -442,6 +442,16 @@ What: /sys/bus/usb/devices/usbX/descriptors
Description:
Contains the interface descriptors, in binary.
What: /sys/bus/usb/devices/usbX/bos_descriptors
Date: March 2024
Contact: Elbert Mai <code@elbertmai.com>
Description:
Binary file containing the cached binary device object store (BOS)
of the device. This consists of the BOS descriptor followed by the
set of device capability descriptors. All descriptors read from
this file are in bus-endian format. Note that the kernel will not
request the BOS from a device if its bcdUSB is less than 0x0201.
What: /sys/bus/usb/devices/usbX/idProduct
Description:
Product ID, in hexadecimal.

View File

@ -19,3 +19,9 @@ Description:
- none
- host
- device
What: /sys/class/usb_role/<switch>/connector
Date: Feb 2024
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Optional symlink to the USB Type-C connector.

View File

@ -205,7 +205,7 @@ Description: Controls the idle timing of system, if there is no FS operation
What: /sys/fs/f2fs/<disk>/discard_idle_interval
Date: September 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
Contact: "Sahitya Tummala" <stummala@codeaurora.org>
Contact: "Sahitya Tummala" <quic_stummala@quicinc.com>
Description: Controls the idle timing of discard thread given
this time interval.
Default is 5 secs.
@ -213,7 +213,7 @@ Description: Controls the idle timing of discard thread given
What: /sys/fs/f2fs/<disk>/gc_idle_interval
Date: September 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
Contact: "Sahitya Tummala" <stummala@codeaurora.org>
Contact: "Sahitya Tummala" <quic_stummala@quicinc.com>
Description: Controls the idle timing for gc path. Set to 5 seconds by default.
What: /sys/fs/f2fs/<disk>/iostat_enable
@ -701,29 +701,31 @@ Description: Support configuring fault injection type, should be
enabled with fault_injection option, fault type value
is shown below, it supports single or combined type.
=================== ===========
Type_Name Type_Value
=================== ===========
FAULT_KMALLOC 0x000000001
FAULT_KVMALLOC 0x000000002
FAULT_PAGE_ALLOC 0x000000004
FAULT_PAGE_GET 0x000000008
FAULT_ALLOC_BIO 0x000000010 (obsolete)
FAULT_ALLOC_NID 0x000000020
FAULT_ORPHAN 0x000000040
FAULT_BLOCK 0x000000080
FAULT_DIR_DEPTH 0x000000100
FAULT_EVICT_INODE 0x000000200
FAULT_TRUNCATE 0x000000400
FAULT_READ_IO 0x000000800
FAULT_CHECKPOINT 0x000001000
FAULT_DISCARD 0x000002000
FAULT_WRITE_IO 0x000004000
FAULT_SLAB_ALLOC 0x000008000
FAULT_DQUOT_INIT 0x000010000
FAULT_LOCK_OP 0x000020000
FAULT_BLKADDR 0x000040000
=================== ===========
=========================== ===========
Type_Name Type_Value
=========================== ===========
FAULT_KMALLOC 0x000000001
FAULT_KVMALLOC 0x000000002
FAULT_PAGE_ALLOC 0x000000004
FAULT_PAGE_GET 0x000000008
FAULT_ALLOC_BIO 0x000000010 (obsolete)
FAULT_ALLOC_NID 0x000000020
FAULT_ORPHAN 0x000000040
FAULT_BLOCK 0x000000080
FAULT_DIR_DEPTH 0x000000100
FAULT_EVICT_INODE 0x000000200
FAULT_TRUNCATE 0x000000400
FAULT_READ_IO 0x000000800
FAULT_CHECKPOINT 0x000001000
FAULT_DISCARD 0x000002000
FAULT_WRITE_IO 0x000004000
FAULT_SLAB_ALLOC 0x000008000
FAULT_DQUOT_INIT 0x000010000
FAULT_LOCK_OP 0x000020000
FAULT_BLKADDR_VALIDITY 0x000040000
FAULT_BLKADDR_CONSISTENCE 0x000080000
FAULT_NO_SEGMENT 0x000100000
=========================== ===========
What: /sys/fs/f2fs/<disk>/discard_io_aware_gran
Date: January 2023

View File

@ -28,7 +28,7 @@ Introduction
high performance safe distributed caching (leases/oplocks), optional packet
signing, large files, Unicode support and other internationalization
improvements. Since both Samba server and this filesystem client support the
CIFS Unix extensions, and the Linux client also suppors SMB3 POSIX extensions,
CIFS Unix extensions, and the Linux client also supports SMB3 POSIX extensions,
the combination can provide a reasonable alternative to other network and
cluster file systems for fileserving in some Linux to Linux environments,
not just in Linux to Windows (or Linux to Mac) environments.

View File

@ -1572,12 +1572,28 @@
The above will cause the "foo" tracing instance to trigger
a snapshot at the end of boot up.
ftrace_dump_on_oops[=orig_cpu]
ftrace_dump_on_oops[=2(orig_cpu) | =<instance>][,<instance> |
,<instance>=2(orig_cpu)]
[FTRACE] will dump the trace buffers on oops.
If no parameter is passed, ftrace will dump
buffers of all CPUs, but if you pass orig_cpu, it will
dump only the buffer of the CPU that triggered the
oops.
If no parameter is passed, ftrace will dump global
buffers of all CPUs, if you pass 2 or orig_cpu, it
will dump only the buffer of the CPU that triggered
the oops, or the specific instance will be dumped if
its name is passed. Multiple instance dump is also
supported, and instances are separated by commas. Each
instance supports only dump on CPU that triggered the
oops by passing 2 or orig_cpu to it.
ftrace_dump_on_oops=foo=orig_cpu
The above will dump only the buffer of "foo" instance
on CPU that triggered the oops.
ftrace_dump_on_oops,foo,bar=orig_cpu
The above will dump global buffer on all CPUs, the
buffer of "foo" instance on all CPUs and the buffer
of "bar" instance on CPU that triggered the oops.
ftrace_filter=[function-list]
[FTRACE] Limit the functions traced by the function
@ -6583,7 +6599,7 @@
To turn off having tracepoints sent to printk,
echo 0 > /proc/sys/kernel/tracepoint_printk
Note, echoing 1 into this file without the
tracepoint_printk kernel cmdline option has no effect.
tp_printk kernel cmdline option has no effect.
The tp_printk_stop_on_boot (see below) can also be used
to stop the printing of events to console at

View File

@ -155,7 +155,7 @@ Setting this parameter to 100 will disable the hysteresis.
Some users cannot tolerate the swapping that comes with zswap store failures
and zswap writebacks. Swapping can be disabled entirely (without disabling
zswap itself) on a cgroup-basis as follows:
zswap itself) on a cgroup-basis as follows::
echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback
@ -166,7 +166,7 @@ writeback (because the same pages might be rejected again and again).
When there is a sizable amount of cold memory residing in the zswap pool, it
can be advantageous to proactively write these cold pages to swap and reclaim
the memory for other use cases. By default, the zswap shrinker is disabled.
User can enable it as follows:
User can enable it as follows::
echo Y > /sys/module/zswap/parameters/shrinker_enabled

View File

@ -31,7 +31,7 @@ The important bits (aka "TL;DR")
Linux kernel regression tracking bot "regzbot" track the issue by specifying
when the regression started like this::
#regzbot introduced v5.13..v5.14-rc1
#regzbot introduced: v5.13..v5.14-rc1
All the details on Linux kernel regressions relevant for users

View File

@ -296,12 +296,30 @@ kernel panic). This will output the contents of the ftrace buffers to
the console. This is very useful for capturing traces that lead to
crashes and outputting them to a serial console.
= ===================================================
0 Disabled (default).
1 Dump buffers of all CPUs.
2 Dump the buffer of the CPU that triggered the oops.
= ===================================================
======================= ===========================================
0 Disabled (default).
1 Dump buffers of all CPUs.
2(orig_cpu) Dump the buffer of the CPU that triggered the
oops.
<instance> Dump the specific instance buffer on all CPUs.
<instance>=2(orig_cpu) Dump the specific instance buffer on the CPU
that triggered the oops.
======================= ===========================================
Multiple instance dump is also supported, and instances are separated
by commas. If global buffer also needs to be dumped, please specify
the dump mode (1/2/orig_cpu) first for global buffer.
So for example to dump "foo" and "bar" instance buffer on all CPUs,
user can::
echo "foo,bar" > /proc/sys/kernel/ftrace_dump_on_oops
To dump global buffer and "foo" instance buffer on all
CPUs along with the "bar" instance buffer on CPU that triggered the
oops, user can::
echo "1,foo,bar=2" > /proc/sys/kernel/ftrace_dump_on_oops
ftrace_enabled, stack_tracer_enabled
====================================

View File

@ -39,13 +39,13 @@ aspects, all of which might be essential in your present case.]*
developers**, execute just the *preparations* and *segment 1*; while doing so,
consider the newest Linux kernel you regularly use to be the 'working' kernel.
In the following example that's assumed to be 6.0.13, which is why the sources
of v6.0 will be used to prepare the .config file.
of 6.0 will be used to prepare the .config file.
**In case you face a regression**, follow the steps at least till the end of
*segment 2*. Then you can submit a preliminary report -- or continue with
*segment 3*, which describes how to perform a bisection needed for a
full-fledged regression report. In the following example 6.0.13 is assumed to be
the 'working' kernel and 6.1.5 to be the first 'broken', which is why v6.0
the 'working' kernel and 6.1.5 to be the first 'broken', which is why 6.0
will be considered the 'good' release and used to prepare the .config file.
* **Preparations**: set up everything to build your own kernels::
@ -99,7 +99,8 @@ will be considered the 'good' release and used to prepare the .config file.
# * Note: on Arch Linux, its derivatives and a few other distributions
# the following commands will do nothing at all or only part of the
# job. See the step-by-step guide for further details.
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
# * Check how much space your self-built kernel actually needs, which
# enables you to make better estimates later:
du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
@ -112,6 +113,7 @@ will be considered the 'good' release and used to prepare the .config file.
# checking if the output of the next two commands matches:
tail -n 1 ~/kernels-built
uname -r
cat /proc/sys/kernel/tainted
c) Check if the problem occurs with this kernel as well.
@ -230,9 +232,10 @@ developers are obliged to act upon.
:ref:`Supplementary tasks: cleanup during and after following this guide.<introclosure_bissbs>`
The steps in each segment illustrate the important aspects of the process, while
a comprehensive reference section holds additional details. The latter sometimes
also outlines alternative approaches, pitfalls, as well as problems that might
occur at the particular step -- and how to get things rolling again.
a comprehensive reference section holds additional details for almost all of the
steps. The reference section sometimes also outlines alternative approaches,
pitfalls, as well as problems that might occur at the particular step -- and how
to get things rolling again.
For further details on how to report Linux kernel issues or regressions check
out Documentation/admin-guide/reporting-issues.rst, which works in conjunction
@ -283,23 +286,23 @@ Preparations: set up everything to build your own kernels
Do you follow this guide to verify if a bug is present in the code developers
care for? Then consider the mainline release your 'working' kernel (the newest
one you regularly use) is based on to be the 'good' version; if your 'working'
kernel for example is '6.0.11', then your 'good' kernel is 'v6.0'.
kernel for example is 6.0.11, then your 'good' kernel is 6.0.
In case you face a regression, it depends on the version range where the
regression was introduced:
* Something which used to work in Linux 6.0 broke when switching to Linux
6.1-rc1? Then henceforth regard 'v6.0' as the last known 'good' version
and 'v6.1-rc1' as the first 'bad' one.
6.1-rc1? Then henceforth regard 6.0 as the last known 'good' version
and 6.1-rc1 as the first 'bad' one.
* Some function stopped working when updating from 6.0.11 to 6.1.4? Then for
the time being consider 'v6.0' as the last 'good' version and 'v6.1.4' as
the time being consider 6.0 as the last 'good' version and 6.1.4 as
the 'bad' one. Note, at this point it is merely assumed that 6.0 is fine;
this assumption will be checked in segment 2.
* A feature you used in 6.0.11 does not work at all or worse in 6.1.13? In
that case you want to bisect within a stable/longterm series: consider
'v6.0.11' as the last known 'good' version and 'v6.0.13' as the first 'bad'
6.0.11 as the last known 'good' version and 6.0.13 as the first 'bad'
one. Note, in this case you still want to compile and test a mainline kernel
as explained in segment 1: the outcome will determine if you need to report
your issue to the regular developers or the stable team.
@ -349,7 +352,7 @@ Preparations: set up everything to build your own kernels
internet connections.*
Execute the following command to retrieve a fresh mainline codebase while
preparing things to add stable/longterm branches later::
preparing things to add branches for stable/longterm series later::
git clone -o mainline --no-checkout \
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux/
@ -368,14 +371,19 @@ Preparations: set up everything to build your own kernels
identifier using ``uname -r``.
Afterwards check out the source code for the version earlier established as
'good' (in this example this is assumed to be 6.0) and create a .config file::
'good'. In the following example command this is assumed to be 6.0; note that
the version number in this and all later Git commands needs to be prefixed
with a 'v'::
git checkout --detach v6.0
Now create a build configuration file::
make olddefconfig
The second command will try to locate the build configuration file for the
running kernel and then adjust it for the needs of the kernel sources you
checked out. While doing so, it will print a few lines you need to check.
The kernel build scripts then will try to locate the build configuration file
for the running kernel and then adjust it for the needs of the kernel sources
you checked out. While doing so, it will print a few lines you need to check.
Look out for a line starting with '# using defaults found in'. It should be
followed by a path to a file in '/boot/' that contains the release identifier
@ -520,44 +528,32 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`]
* Install your newly built kernel.
Before doing so, consider checking if there is still enough room for it::
Before doing so, consider checking if there is still enough space for it::
df -h /boot/ /lib/modules/
150 MByte in /boot/ and 200 in /lib/modules/ usually suffice. Those are rough
estimates assuming the worst case. How much your kernels actually require will
be determined later.
For now assume 150 MByte in /boot/ and 200 in /lib/modules/ will suffice; how
much your kernels actually require will be determined later during this guide.
Now install the kernel, which will be saved in parallel to the kernels from
your Linux distribution::
Now install the kernel's modules and its image, which will be stored in
parallel to the your Linux distribution's kernels::
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
On many commodity Linux distributions this will take care of everything
required to boot your kernel. You might want to ensure that's the case by
checking if your boot loader's configuration was updated; furthermore ensure
an initramfs (also known as initrd) exists, which on many distributions can be
achieved by running ``ls -l /boot/init*$(make -s kernelrelease)*``. Those
steps are recommended, as there are quite a few Linux distribution where above
command is insufficient:
The second command ideally will take care of three steps required at this
point: copying the kernel's image to /boot/, generating an initramfs, and
adding an entry for both to the boot loader's configuration.
* On Arch Linux, its derivatives, many immutable Linux distributions, and a
few others the above command does nothing at, as they lack 'installkernel'
executable.
Sadly some distributions (among them Arch Linux, its derivatives, and many
immutable Linux distributions) will perform none or only some of those tasks.
You therefore want to check if all of them were taken care of and manually
perform those that were not. The reference section provides further details on
that; your distribution's documentation might help, too.
* Some distributions install the kernel, but don't add an entry for your
kernel in your boot loader's configuration -- the kernel thus won't show up
in the boot menu.
* Some distributions add a boot loader menu entry, but don't create an
initramfs on installation -- in that case your kernel most likely will be
unable to mount the root partition during bootup.
If any of that applies to you, see the reference section for further guidance.
Once you figured out what to do, consider writing down the necessary
installation steps: if you will build more kernels as described in
segment 2 and 3, you will have to execute these commands every time that
``command -v installkernel [...]`` comes up again.
Once you figured out the steps needed at this point, consider writing them
down: if you will build more kernels as described in segment 2 and 3, you will
have to perform those again after executing ``command -v installkernel [...]``.
[:ref:`details<install_bisref>`]
@ -583,31 +579,40 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`]
Remember the identifier momentarily, as it will help you pick the right kernel
from the boot menu upon restarting.
.. _recheckbroken_bissbs:
* Reboot into the kernel you just built and check if the feature that is
expected to be broken really is.
Start by making sure the kernel you booted is the one you just built. When
unsure, check if the output of these commands show the exact same release
identifier::
* Reboot into your newly built kernel. To ensure your actually started the one
you just built, you might want to verify if the output of these commands
matches::
tail -n 1 ~/kernels-built
uname -r
Now verify if the feature that causes trouble works with your newly built
kernel. If things work while investigating a regression, check the reference
section for further details.
.. _tainted_bissbs:
* Check if the kernel marked itself as 'tainted'::
cat /proc/sys/kernel/tainted
If that command does not return '0', check the reference section, as the cause
for this might interfere with your testing.
[:ref:`details<tainted_bisref>`]
.. _recheckbroken_bissbs:
* Verify if your bug occurs with the newly built kernel. If it does not, check
out the instructions in the reference section to ensure nothing went sideways
during your tests.
[:ref:`details<recheckbroken_bisref>`]
.. _recheckstablebroken_bissbs:
* Are you facing a problem within a stable/longterm release, but failed to
reproduce it with the mainline kernel you just built? Then check if the latest
codebase for the particular series might already fix the problem. To do so,
add the stable series Git branch for your 'good' kernel (again, this here is
assumed to be 6.0) and check out the latest version::
* Are you facing a problem within a stable/longterm series, but failed to
reproduce it with the mainline kernel you just built? One that according to
the `front page of kernel.org <https://kernel.org/>`_ is still supported? Then
check if the latest codebase for the particular series might already fix the
problem. To do so, add the stable series Git branch for your 'good' kernel
(again, this here is assumed to be 6.0) and check out the latest version::
cd ~/linux/
git remote set-branches --add stable linux-6.0.y
@ -622,22 +627,26 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`]
make -j $(nproc --all)
# * Check if the free space suffices holding another kernel:
df -h /boot/ /lib/modules/
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
make -s kernelrelease | tee -a ~/kernels-built
reboot
Now verify if you booted the kernel you intended to start, to then check if
everything works fine with this kernel::
Confirm you booted the kernel you intended to start and check its tainted
status::
tail -n 1 ~/kernels-built
uname -r
cat /proc/sys/kernel/tainted
Now verify if this kernel is showing the problem.
[:ref:`details<recheckstablebroken_bisref>`]
Do you follow this guide to verify if a problem is present in the code
currently supported by Linux kernel developers? Then you are done at this
point. If you later want to remove the kernel you just built, check out
:ref:`Supplementary tasks: cleanup during and after following this guide.<introclosure_bissbs>`.
:ref:`Supplementary tasks: cleanup during and after following this guide<introclosure_bissbs>`.
In case you face a regression, move on and execute at least the next segment
as well.
@ -670,12 +679,13 @@ otherwise would be a waste of time. [:ref:`details<introworkingcheck_bisref>`]
make -j $(nproc --all)
# * Check if the free space suffices holding another kernel:
df -h /boot/ /lib/modules/
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
make -s kernelrelease | tee -a ~/kernels-built
reboot
When the system booted, you may want to verify once again that the
kernel you started is the one you just built:
kernel you started is the one you just built::
tail -n 1 ~/kernels-built
uname -r
@ -698,7 +708,7 @@ configuration created earlier this works a lot faster than many people assume:
overall on average it will often just take about 10 to 15 minutes to compile
each kernel on commodity x86 machines.
* In case your 'bad' version is a stable/longterm release (say v6.1.5), add its
* In case your 'bad' version is a stable/longterm release (say 6.1.5), add its
stable branch, unless you already did so earlier::
cd ~/linux/
@ -727,7 +737,8 @@ each kernel on commodity x86 machines.
make -j $(nproc --all)
# * Check if the free space suffices holding another kernel:
df -h /boot/ /lib/modules/
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
make -s kernelrelease | tee -a ~/kernels-built
reboot
@ -843,7 +854,8 @@ each kernel on commodity x86 machines.
make -j $(nproc --all) &&
# * Check if the free space suffices holding another kernel:
df -h /boot/ /lib/modules/
command -v installkernel && sudo make modules_install install
sudo make modules_install
command -v installkernel && sudo make install
Make -s kernelrelease | tee -a ~/kernels-built
reboot
@ -1126,12 +1138,12 @@ Git clone of Linus' mainline repository. There is nothing more to say about
that -- but there are two alternatives ways to retrieve the sources that might
work better for you:
* If you have an unreliable internet connection, consider
:ref:`using a 'Git bundle'<sources_bundle_bisref>`.
* If you have an unreliable internet connection, consider
:ref:`using a 'Git bundle'<sources_bundle_bisref>`.
* If downloading the complete repository would take too long or requires too
much storage space, consider :ref:`using a 'shallow
clone'<sources_shallow_bisref>`.
* If downloading the complete repository would take too long or requires too
much storage space, consider :ref:`using a 'shallow
clone'<sources_shallow_bisref>`.
.. _sources_bundle_bisref:
@ -1183,23 +1195,23 @@ branches as explained in the step-by-step guide.
Note, shallow clones have a few peculiar characteristics:
* For bisections the history needs to be deepened a few mainline versions
farther than it seems necessary, as explained above already. That's because
Git otherwise will be unable to revert or describe most of the commits within
a range (say v6.1..v6.2), as they are internally based on earlier kernels
releases (like v6.0-rc2 or 5.19-rc3).
* For bisections the history needs to be deepened a few mainline versions
farther than it seems necessary, as explained above already. That's because
Git otherwise will be unable to revert or describe most of the commits within
a range (say 6.1..6.2), as they are internally based on earlier kernels
releases (like 6.0-rc2 or 5.19-rc3).
* This document in most places uses ``git fetch`` with ``--shallow-exclude=``
to specify the earliest version you care about (or to be precise: its git
tag). You alternatively can use the parameter ``--shallow-since=`` to specify
an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
define the depth of the history you want to download. When using them while
bisecting mainline, ensure to deepen the history to at least 7 months before
the release of the mainline release your 'good' kernel is based on.
* This document in most places uses ``git fetch`` with ``--shallow-exclude=``
to specify the earliest version you care about (or to be precise: its git
tag). You alternatively can use the parameter ``--shallow-since=`` to specify
an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
define the depth of the history you want to download. When using them while
bisecting mainline, ensure to deepen the history to at least 7 months before
the release of the mainline release your 'good' kernel is based on.
* Be warned, when deepening your clone you might encounter an error like
'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'.
In that case run ``git repack -d`` and try again.
* Be warned, when deepening your clone you might encounter an error like
'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'.
In that case run ``git repack -d`` and try again.
[:ref:`back to step-by-step guide <sources_bissbs>`]
[:ref:`back to section intro <sources_bisref>`]
@ -1223,23 +1235,23 @@ locate the right build configuration.*
Two things can easily go wrong when creating a .config file as advised:
* The oldconfig target will use a .config file from your build directory, if
one is already present there (e.g. '~/linux/.config'). That's totally fine if
that's what you intend (see next step), but in all other cases you want to
delete it. This for example is important in case you followed this guide
further, but due to problems come back here to redo the configuration from
scratch.
* The oldconfig target will use a .config file from your build directory, if
one is already present there (e.g. '~/linux/.config'). That's totally fine if
that's what you intend (see next step), but in all other cases you want to
delete it. This for example is important in case you followed this guide
further, but due to problems come back here to redo the configuration from
scratch.
* Sometimes olddefconfig is unable to locate the .config file for your running
kernel and will use defaults, as briefly outlined in the guide. In that case
check if your distribution ships the configuration somewhere and manually put
it in the right place (e.g. '~/linux/.config') if it does. On distributions
where /proc/config.gz exists this can be achieved using this command::
* Sometimes olddefconfig is unable to locate the .config file for your running
kernel and will use defaults, as briefly outlined in the guide. In that case
check if your distribution ships the configuration somewhere and manually put
it in the right place (e.g. '~/linux/.config') if it does. On distributions
where /proc/config.gz exists this can be achieved using this command::
zcat /proc/config.gz > .config
zcat /proc/config.gz > .config
Once you put it there, run ``make olddefconfig`` again to adjust it to the
needs of the kernel about to be built.
Once you put it there, run ``make olddefconfig`` again to adjust it to the
needs of the kernel about to be built.
Note, the olddefconfig target will set any undefined build options to their
default value. If you prefer to set such configuration options manually, use
@ -1252,7 +1264,7 @@ restrictions).
Occasionally odd things happen when trying to use a config file prepared for one
kernel (say 6.1) on an older mainline release -- especially if it is much older
(say v5.15). That's one of the reasons why the previous step in the guide told
(say 5.15). That's one of the reasons why the previous step in the guide told
you to boot the kernel where everything works. If you manually add a .config
file you thus want to ensure it's from the working kernel and not from a one
that shows the regression.
@ -1381,16 +1393,16 @@ when following this guide on a few commodity distributions.
**Debian:**
* Remove a stale reference to a certificate file that would cause your build to
fail::
* Remove a stale reference to a certificate file that would cause your build to
fail::
./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
Alternatively, download the needed certificate and make that configuration
option point to it, as `the Debian handbook explains in more detail
<https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
-- or generate your own, as explained in
Documentation/admin-guide/module-signing.rst.
Alternatively, download the needed certificate and make that configuration
option point to it, as `the Debian handbook explains in more detail
<https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
-- or generate your own, as explained in
Documentation/admin-guide/module-signing.rst.
[:ref:`back to step-by-step guide <configmods_bissbs>`]
@ -1402,12 +1414,12 @@ Individual adjustments
*If you want to influence the other aspects of the configuration, do so
now.* [:ref:`... <configmods_bissbs>`]
You at this point can use a command like ``make menuconfig`` to enable or
disable certain features using a text-based user interface; to use a graphical
configuration utility, call the make target ``xconfig`` or ``gconfig`` instead.
All of them require development libraries from toolkits they are based on
(ncurses, Qt5, Gtk2); an error message will tell you if something required is
missing.
At this point you can use a command like ``make menuconfig`` or ``make nconfig``
to enable or disable certain features using a text-based user interface; to use
a graphical configuration utility, run ``make xconfig`` instead. Both of them
require development libraries from toolkits they are rely on (ncurses
respectively Qt5 or Qt6); an error message will tell you if something required
is missing.
[:ref:`back to step-by-step guide <configmods_bissbs>`]
@ -1484,10 +1496,10 @@ highly recommended for these reasons:
.. _checkoutmaster_bisref:
Checkout the latest Linux codebase
----------------------------------
Check out the latest Linux codebase
-----------------------------------
*Checkout the latest Linux codebase.*
*Check out the latest Linux codebase.*
[:ref:`... <introlatestcheck_bissbs>`]
In case you later want to recheck if an ever newer codebase might fix the
@ -1515,7 +1527,7 @@ When a build error occurs, it might be caused by some aspect of your machine's
setup that often can be fixed quickly; other times though the problem lies in
the code and can only be fixed by a developer. A close examination of the
failure messages coupled with some research on the internet will often tell you
which of the two it is. To perform such a investigation, restart the build
which of the two it is. To perform such investigation, restart the build
process like this::
make V=1
@ -1538,10 +1550,10 @@ often one of the hits will provide a solution for your problem, too. If you
do not find anything that matches your problem, try again from a different angle
by modifying your search terms or using another line from the error messages.
In the end, most trouble you are to run into has likely been encountered and
In the end, most issues you run into have likely been encountered and
reported by others already. That includes issues where the cause is not your
system, but lies the code. If you run into one of those, you might thus find a
solution (e.g. a patch) or workaround for your problem, too.
system, but lies in the code. If you run into one of those, you might thus find a
solution (e.g. a patch) or workaround for your issue, too.
Package your kernel up
~~~~~~~~~~~~~~~~~~~~~~
@ -1551,11 +1563,11 @@ The step-by-step guide uses the default make targets (e.g. 'bzImage' and
steps of the guide then install. You instead can also directly build everything
and directly package it up by using one of the following targets:
* ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
* ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
* ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
* ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
* ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
* ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
This is just a selection of available make targets for this purpose, see
``make help`` for others. You can also use these targets after running
@ -1580,39 +1592,38 @@ Put the kernel in place
*Install the kernel you just built.* [:ref:`... <install_bissbs>`]
What you need to do after executing the command in the step-by-step guide
depends on the existence and the implementation of an ``installkernel``
executable. Many commodity Linux distributions ship such a kernel installer in
'/sbin/' that does everything needed, hence there is nothing left for you
except rebooting. But some distributions contain an installkernel that does
only part of the job -- and a few lack it completely and leave all the work to
you.
depends on the existence and the implementation of ``/sbin/installkernel``
executable on your distribution.
If ``installkernel`` is found, the kernel's build system will delegate the
actual installation of your kernel's image and related files to this executable.
On almost all Linux distributions it will store the image as '/boot/vmlinuz-
<kernelrelease identifier>' and put a 'System.map-<kernelrelease
identifier>' alongside it. Your kernel will thus be installed in parallel to any
existing ones, unless you already have one with exactly the same release name.
If installkernel is found, the kernel's build system will delegate the actual
installation of your kernel image to this executable, which then performs some
or all of these tasks:
Installkernel on many distributions will afterwards generate an 'initramfs'
(often also called 'initrd'), which commodity distributions rely on for booting;
hence be sure to keep the order of the two make targets used in the step-by-step
guide, as things will go sideways if you install your kernel's image before its
modules. Often installkernel will then add your kernel to the bootloader
configuration, too. You have to take care of one or both of these tasks
yourself, if your distributions installkernel doesn't handle them.
* On almost all Linux distributions installkernel will store your kernel's
image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will
put a 'System.map-<kernelrelease_id>' alongside it.
A few distributions like Arch Linux and its derivatives totally lack an
installkernel executable. On those just install the modules using the kernel's
build system and then install the image and the System.map file manually::
* On most distributions installkernel will then generate an 'initramfs'
(sometimes also called 'initrd'), which usually are stored as
'/boot/initramfs-<kernelrelease_id>.img' or
'/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file
for booting, hence ensure to execute the make target 'modules_install' first,
as your distribution's initramfs generator otherwise will be unable to find
the modules that go into the image.
* On some distributions installkernel will then add an entry for your kernel
to your bootloader's configuration.
You have to take care of some or all of the tasks yourself, if your
distribution lacks a installkernel script or does only handle part of them.
Consult the distribution's documentation for details. If in doubt, install the
kernel manually::
sudo make modules_install
sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
If your distribution boots with the help of an initramfs, now generate one for
your kernel using the tools your distribution provides for this process.
Afterwards add your kernel to your bootloader configuration and reboot.
Now generate your initramfs using the tools your distribution provides for this
process. Afterwards add your kernel to your bootloader configuration and reboot.
[:ref:`back to step-by-step guide <install_bissbs>`]
@ -1637,20 +1648,39 @@ need to look in different places.
[:ref:`back to step-by-step guide <storagespace_bissbs>`]
.. _tainted_bisref:
Check if your newly built kernel considers itself 'tainted'
-----------------------------------------------------------
*Check if the kernel marked itself as 'tainted'.*
[:ref:`... <tainted_bissbs>`]
Linux marks itself as tainted when something happens that potentially leads to
follow-up errors that look totally unrelated. That is why developers might
ignore or react scantly to reports from tainted kernels -- unless of course the
kernel set the flag right when the reported bug occurred.
That's why you want check why a kernel is tainted as explained in
Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own
interest, as your testing might be flawed otherwise.
[:ref:`back to step-by-step guide <tainted_bissbs>`]
.. _recheckbroken_bisref:
Check the kernel built from the latest codebase
-----------------------------------------------
Check the kernel built from a recent mainline codebase
------------------------------------------------------
*Reboot into the kernel you just built and check if the feature that regressed
is really broken there.* [:ref:`... <recheckbroken_bissbs>`]
*Verify if your bug occurs with the newly built kernel.*
[:ref:`... <recheckbroken_bissbs>`]
There are a couple of reasons why the regression you face might not show up with
your own kernel built from the latest codebase. These are the most frequent:
There are a couple of reasons why your bug or regression might not show up with
the kernel you built from the latest codebase. These are the most frequent:
* The cause for the regression was fixed meanwhile.
* The bug was fixed meanwhile.
* The regression with the broken kernel was caused by a change in the build
* What you suspected to be a regression was caused by a change in the build
configuration the provider of your kernel carried out.
* Your problem might be a race condition that does not show up with your kernel;
@ -1702,9 +1732,9 @@ it's possible that the thing that regressed might never have worked in vanilla
builds of the 'good' version in the first place.
There is a third reason for those that noticed a regression between
stable/longterm kernels of different series (e.g. v6.0.13..v6.1.5): it will
stable/longterm kernels of different series (e.g. 6.0.13..6.1.5): it will
ensure the kernel version you assumed to be 'good' earlier in the process (e.g.
v6.0) actually is working.
6.0) actually is working.
[:ref:`back to step-by-step guide <introworkingcheck_bissbs>`]
@ -1720,6 +1750,9 @@ In case the feature that broke with newer kernels does not work with your first
self-built kernel, find and resolve the cause before moving on. There are a
multitude of reasons why this might happen. Some ideas where to look:
* Check the taint status and the output of ``dmesg``, maybe something unrelated
went wrong.
* Maybe localmodconfig did something odd and disabled the module required to
test the feature? Then you might want to recreate a .config file based on the
one from the last working kernel and skip trimming it down; manually disabling
@ -1734,8 +1767,8 @@ multitude of reasons why this might happen. Some ideas where to look:
Note, if you found and fixed problems with the .config file, you want to use it
to build another kernel from the latest codebase, as your earlier tests with
mainline and the latest version from an affected stable/longterm series most
likely has been flawed.
mainline and the latest version from an affected stable/longterm series were most
likely flawed.
[:ref:`back to step-by-step guide <recheckworking_bissbs>`]
@ -1748,8 +1781,8 @@ Start the bisection
'good' and 'bad'.* [:ref:`... <bisectstart_bissbs>`]
This will start the bisection process; the last of the commands will make Git
checkout a commit round about half-way between the 'good' and the 'bad' changes
for your to test.
check out a commit round about half-way between the 'good' and the 'bad' changes
for you to test.
[:ref:`back to step-by-step guide <bisectstart_bissbs>`]
@ -1774,7 +1807,7 @@ There are two things worth of note here:
* Those slightly odd looking version identifiers can happen during bisections,
because the Linux kernel subsystems prepare their changes for a new mainline
release (say 6.2) before its predecessor (e.g. 6.1) is finished. They thus
base them on a somewhat earlier point like v6.1-rc1 or even v6.0 -- and then
base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then
get merged for 6.2 without rebasing nor squashing them once 6.1 is out. This
leads to those slightly odd looking version identifiers coming up during
bisections.
@ -1790,7 +1823,7 @@ Bisection checkpoint
[:ref:`... <bisecttest_bissbs>`]
Ensure what you tell Git is accurate: getting it wrong just one time will bring
the rest of the bisection totally of course, hence all testing after that point
the rest of the bisection totally off course, hence all testing after that point
will be for nothing.
[:ref:`back to step-by-step guide <bisecttest_bissbs>`]
@ -1811,7 +1844,7 @@ instead of testing ten or more kernels you might only have to build a few to
resolve things.
The .config file is put aside, as there is a decent chance that developers might
ask for it after you reported the regression.
ask for it after you report the regression.
[:ref:`back to step-by-step guide <bisectlog_bissbs>`]
@ -1861,7 +1894,7 @@ simply remove its modules directory in /lib/modules/.
The other place is /boot/, where typically two up to five files will be placed
during installation of a kernel. All of them usually contain the release name in
their file name, but how many files and their exact name depends somewhat on
their file name, but how many files and their exact names depend somewhat on
your distribution's installkernel executable and its initramfs generator. On
some distributions the ``kernel-install remove...`` command mentioned in the
step-by-step guide will delete all of these files for you while also removing

View File

@ -144,14 +144,8 @@ passing 0 into the hint address parameter of mmap. On CPUs with an address space
smaller than sv48, the CPU maximum supported address space will be the default.
Software can "opt-in" to receiving VAs from another VA space by providing
a hint address to mmap. A hint address passed to mmap will cause the largest
address space that fits entirely into the hint to be used, unless there is no
space left in the address space. If there is no space available in the requested
address space, an address in the next smallest available address space will be
returned.
For example, in order to obtain 48-bit VA space, a hint address greater than
:code:`1 << 47` must be provided. Note that this is 47 due to sv48 userspace
ending at :code:`1 << 47` and the addresses beyond this are reserved for the
kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
than or equal to :code:`1 << 56` must be provided.
a hint address to mmap. When a hint address is passed to mmap, the returned
address will never use more bits than the hint address. For example, if a hint
address of `1 << 40` is passed to mmap, a valid returned address will never use
bits 41 through 63. If no mappable addresses are available in that range, mmap
will return `MAP_FAILED`.

View File

@ -45,7 +45,7 @@ mount options are:
Enable code/data prioritization in L2 cache allocations.
"mba_MBps":
Enable the MBA Software Controller(mba_sc) to specify MBA
bandwidth in MBps
bandwidth in MiBps
"debug":
Make debug files accessible. Available debug files are annotated with
"Available only with debug option".
@ -526,7 +526,7 @@ threads start using more cores in an rdtgroup, the actual bandwidth may
increase or vary although user specified bandwidth percentage is same.
In order to mitigate this and make the interface more user friendly,
resctrl added support for specifying the bandwidth in MBps as well. The
resctrl added support for specifying the bandwidth in MiBps as well. The
kernel underneath would use a software feedback mechanism or a "Software
Controller(mba_sc)" which reads the actual bandwidth using MBM counters
and adjust the memory bandwidth percentages to ensure::
@ -573,13 +573,13 @@ Memory b/w domain is L3 cache.
MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
Memory bandwidth Allocation specified in MBps
---------------------------------------------
Memory bandwidth Allocation specified in MiBps
----------------------------------------------
Memory bandwidth domain is L3 cache.
::
MB:<cache_id0>=bw_MBps0;<cache_id1>=bw_MBps1;...
MB:<cache_id0>=bw_MiBps0;<cache_id1>=bw_MiBps1;...
Slow Memory Bandwidth Allocation (SMBA)
---------------------------------------

View File

@ -104,6 +104,8 @@ Some of these tools are listed below:
KASAN and can be used in production. See Documentation/dev-tools/kfence.rst
* lockdep is a locking correctness validator. See
Documentation/locking/lockdep-design.rst
* Runtime Verification (RV) supports checking specific behaviours for a given
subsystem. See Documentation/trace/rv/runtime-verification.rst
* There are several other pieces of debug instrumentation in the kernel, many
of which can be found in lib/Kconfig.debug

View File

@ -44,14 +44,21 @@ properties:
minItems: 1
maxItems: 2
qcom,dsb-element-size:
qcom,dsb-element-bits:
description:
Specifies the DSB(Discrete Single Bit) element size supported by
the monitor. The associated aggregator will read this size before it
is enabled. DSB element size currently only supports 32-bit and 64-bit.
$ref: /schemas/types.yaml#/definitions/uint8
enum: [32, 64]
qcom,cmb-element-bits:
description:
Specifies the CMB(Continuous Multi-Bit) element size supported by
the monitor. The associated aggregator will read this size before it
is enabled. CMB element size currently only supports 8-bit, 32-bit
and 64-bit.
enum: [8, 32, 64]
qcom,dsb-msrs-num:
description:
Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
@ -61,6 +68,15 @@ properties:
minimum: 0
maximum: 32
qcom,cmb-msrs-num:
description:
Specifies the number of CMB MSR(mux select register) registers supported
by the monitor. If this property is not configured or set to 0, it means
this TPDM doesn't support CMB MSR.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 32
clocks:
maxItems: 1
@ -94,7 +110,7 @@ examples:
compatible = "qcom,coresight-tpdm", "arm,primecell";
reg = <0x0684c000 0x1000>;
qcom,dsb-element-size = /bits/ 8 <32>;
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <16>;
clocks = <&aoss_qmp>;
@ -110,4 +126,22 @@ examples:
};
};
tpdm@6c29000 {
compatible = "qcom,coresight-tpdm", "arm,primecell";
reg = <0x06c29000 0x1000>;
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
out-ports {
port {
tpdm_ipcc_out_funnel_center: endpoint {
remote-endpoint = <&funnel_center_in_tpdm_ipcc>;
};
};
};
};
...

View File

@ -18,6 +18,7 @@ properties:
- const: brcm,gisb-arb
- items:
- enum:
- brcm,bcm74165-gisb-arb # for V7 new style 16nm chips
- brcm,bcm7278-gisb-arb # for V7 28nm chips
- brcm,bcm7435-gisb-arb # for newer 40nm chips
- brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips

View File

@ -1,5 +1,3 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for Keystone gate control driver which uses PSC controller IP.
This binding uses the common clock binding[1].

View File

@ -1,5 +1,3 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for keystone PLLs. The main PLL IP typically has a multiplier,
a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
and PAPLL are controlled by the memory mapped register where as the Main

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments ADPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped ADPLL with two to three selectable input clocks
and three to four children.

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments APLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped APLL with usually two selectable input clocks
(reference clock and bypass clock), with analog phase locked

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments autoidle clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a register mapped
clock which can be put to idle automatically by hardware based on the usage
and a configuration bit setting. Autoidle clock is never an individual

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments clockdomain.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1] in consumer role.
Every clock on TI SoC belongs to one clockdomain, but software
only needs this information for specific clocks which require

View File

@ -1,7 +1,5 @@
Binding for TI composite clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped composite clock with multiple different sub-types;

View File

@ -1,7 +1,5 @@
Binding for TI divider clock
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped adjustable clock rate divider that does not gate and has
only one input clock or parent. By default the value programmed into

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments DPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped DPLL with usually two selectable input clocks
(reference clock and bypass clock), with digital phase locked

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments FAPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped FAPLL with usually two selectable input clocks
(reference clock and bypass clock), and one or more child

View File

@ -1,7 +1,5 @@
Binding for TI fixed factor rate clock sources.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1], and also uses the autoidle
support from TI autoidle clock [2].

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments gate clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. This clock is
quite much similar to the basic gate-clock [2], however,
it supports a number of additional features. If no register

View File

@ -1,7 +1,5 @@
Binding for Texas Instruments interface clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. This clock is
quite much similar to the basic gate-clock [2], however,
it supports a number of additional features, including

View File

@ -1,7 +1,5 @@
Binding for TI mux clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped multiplexer with multiple input clock signals or
parents, one of which can be selected as output. This clock does not

View File

@ -144,6 +144,8 @@ Example::
#dma-cells = <1>;
clocks = <&clock_controller 0>, <&clock_controller 1>;
clock-names = "bus", "host";
#address-cells = <1>;
#size-cells = <1>;
vendor,custom-property = <2>;
status = "disabled";

View File

@ -270,7 +270,7 @@ examples:
port {
ov7251_ep: endpoint {
data-lanes = <0 1>;
data-lanes = <0>;
link-frequencies = /bits/ 64 <240000000 319200000>;
remote-endpoint = <&csiphy3_ep>;
};

View File

@ -14,9 +14,6 @@ description: The Nomadik I2C host controller began its life in the ST
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
@ -24,21 +21,23 @@ select:
contains:
enum:
- st,nomadik-i2c
- mobileye,eyeq5-i2c
required:
- compatible
properties:
compatible:
oneOf:
# The variant found in STn8815
- items:
- const: st,nomadik-i2c
- const: arm,primecell
# The variant found in DB8500
- items:
- const: stericsson,db8500-i2c
- const: st,nomadik-i2c
- const: arm,primecell
- items:
- const: mobileye,eyeq5-i2c
- const: arm,primecell
reg:
maxItems: 1
@ -55,7 +54,7 @@ properties:
- items:
- const: mclk
- const: apb_pclk
# Clock name in DB8500
# Clock name in DB8500 or EyeQ5
- items:
- const: i2cclk
- const: apb_pclk
@ -70,6 +69,16 @@ properties:
minimum: 1
maximum: 400000
mobileye,olb:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: Phandle to OLB system controller node.
- description: Platform-wide controller ID (integer starting from zero).
description:
The phandle pointing to OLB system controller node, with the I2C
controller index.
required:
- compatible
- reg
@ -79,6 +88,20 @@ required:
unevaluatedProperties: false
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
- if:
properties:
compatible:
contains:
const: mobileye,eyeq5-i2c
then:
required:
- mobileye,olb
else:
properties:
mobileye,olb: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
@ -111,5 +134,19 @@ examples:
clocks = <&i2c0clk>, <&pclki2c0>;
clock-names = "mclk", "apb_pclk";
};
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
i2c@300000 {
compatible = "mobileye,eyeq5-i2c", "arm,primecell";
reg = <0x300000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 1 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&i2c_ser_clk>, <&i2c_clk>;
clock-names = "i2cclk", "apb_pclk";
mobileye,olb = <&olb 0>;
};
...

View File

@ -22,7 +22,6 @@ properties:
maxItems: 1
label:
$ref: /schemas/types.yaml#/definitions/string
description: Unique name to identify which channel this is.
bipolar:

View File

@ -44,6 +44,9 @@ properties:
Pin that controls the powerdown mode of the device.
maxItems: 1
io-backends:
maxItems: 1
reset-gpios:
description:
Reset pin for the device.
@ -68,6 +71,7 @@ examples:
reg = <0>;
clocks = <&adc_clk>;
clock-names = "adc-clk";
io-backends = <&iio_backend>;
};
};
...

View File

@ -39,12 +39,15 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description:
A reference to a the actual ADC to which this FPGA ADC interfaces to.
deprecated: true
'#io-backend-cells':
const: 0
required:
- compatible
- dmas
- reg
- adi,adc-dev
additionalProperties: false
@ -55,7 +58,6 @@ examples:
reg = <0x44a00000 0x10000>;
dmas = <&rx_dma 0>;
dma-names = "rx";
adi,adc-dev = <&spi_adc>;
#io-backend-cells = <0>;
};
...

View File

@ -0,0 +1,120 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/microchip,pac1934.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip PAC1934 Power Monitors with Accumulator
maintainers:
- Marius Cristea <marius.cristea@microchip.com>
description: |
This device is part of the Microchip family of Power Monitors with
Accumulator.
The datasheet for PAC1931, PAC1932, PAC1933 and PAC1934 can be found here:
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/PAC1931-Family-Data-Sheet-DS20005850E.pdf
properties:
compatible:
enum:
- microchip,pac1931
- microchip,pac1932
- microchip,pac1933
- microchip,pac1934
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
interrupts:
maxItems: 1
slow-io-gpios:
description:
A GPIO used to trigger a change is sampling rate (lowering the chip power
consumption). If configured in SLOW mode, if this pin is forced high,
sampling rate is forced to eight samples/second. When it is forced low,
the sampling rate is 1024 samples/second unless a different sample rate
has been programmed.
patternProperties:
"^channel@[1-4]+$":
type: object
$ref: adc.yaml
description:
Represents the external channels which are connected to the ADC.
properties:
reg:
items:
minimum: 1
maximum: 4
shunt-resistor-micro-ohms:
description:
Value in micro Ohms of the shunt resistor connected between
the SENSE+ and SENSE- inputs, across which the current is measured.
Value is needed to compute the scaling of the measured current.
required:
- reg
- shunt-resistor-micro-ohms
unevaluatedProperties: false
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
power-monitor@10 {
compatible = "microchip,pac1934";
reg = <0x10>;
#address-cells = <1>;
#size-cells = <0>;
channel@1 {
reg = <0x1>;
shunt-resistor-micro-ohms = <24900000>;
label = "CPU";
};
channel@2 {
reg = <0x2>;
shunt-resistor-micro-ohms = <49900000>;
label = "GPU";
};
channel@3 {
reg = <0x3>;
shunt-resistor-micro-ohms = <75000000>;
label = "MEM";
bipolar;
};
channel@4 {
reg = <0x4>;
shunt-resistor-micro-ohms = <100000000>;
label = "NET";
bipolar;
};
};
};
...

View File

@ -31,7 +31,6 @@ properties:
- description: normal conversion, include EOC (End of Conversion),
ECH (End of Chain), JEOC (End of Injected Conversion) and
JECH (End of injected Chain).
- description: Self-testing Interrupts.
clocks:
maxItems: 1
@ -70,8 +69,7 @@ examples:
reg = <0x44530000 0x10000>;
interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
<GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX93_CLK_ADC1_GATE>;
clock-names = "ipg";
vref-supply = <&reg_vref_1v8>;

View File

@ -75,7 +75,6 @@ patternProperties:
in the PMIC-specific files in include/dt-bindings/iio/.
label:
$ref: /schemas/types.yaml#/definitions/string
description: |
ADC input of the platform as seen in the schematics.
For thermistor inputs connected to generic AMUX or GPIO inputs

View File

@ -25,7 +25,14 @@ description: |
properties:
compatible:
const: richtek,rtq6056
oneOf:
- enum:
- richtek,rtq6056
- richtek,rtq6059
- items:
- enum:
- richtek,rtq6053
- const: richtek,rtq6056
reg:
maxItems: 1

View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/ti,ads1298.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments' ads1298 medical ADC chips
description: |
Datasheet at: https://www.ti.com/product/ADS1298
Bindings for this chip aren't complete.
maintainers:
- Mike Looijmans <mike.looijmans@topic.nl>
properties:
compatible:
enum:
- ti,ads1298
reg:
maxItems: 1
spi-cpha: true
reset-gpios:
maxItems: 1
avdd-supply:
description:
Analog power supply, voltage between AVDD and AVSS. When providing a
symmetric +/- 2.5V, the regulator should report 5V.
vref-supply:
description:
Optional reference voltage. If omitted, internal reference is used,
which is 2.4V when analog supply is below 4.4V, 4V otherwise.
clocks:
description: Optional 2.048 MHz external source clock on CLK pin
maxItems: 1
interrupts:
description: Interrupt on DRDY pin, triggers on falling edge
maxItems: 1
label: true
required:
- compatible
- reg
- avdd-supply
- interrupts
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
adc@1 {
reg = <1>;
compatible = "ti,ads1298";
label = "ads1298-1-ecg";
avdd-supply = <&reg_iso_5v_a>;
clocks = <&clk_ads1298>;
interrupt-parent = <&gpio0>;
interrupts = <78 IRQ_TYPE_EDGE_FALLING>;
spi-max-frequency = <20000000>;
spi-cpha;
};
};
...

View File

@ -39,6 +39,17 @@ properties:
description: |
Channel node of a voltage io-channel.
'#io-channel-cells':
description:
In addition to consuming the measurement services of a voltage
output channel, the voltage divider can act as a provider of
measurement services to other devices. This is particularly
useful in scenarios wherein an ADC has an analog frontend,
such as a voltage divider, and then consuming its raw value
isn't interesting. In this case, the voltage before the divider
is desired.
const: 1
output-ohms:
description:
Resistance Rout over which the output voltage is measured. See full-ohms.

View File

@ -21,6 +21,8 @@ description: |
HMC540S 1 dB LSB Silicon MMIC 4-Bit Digital Positive Control Attenuator, 0.1 - 8 GHz
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc540s.pdf
LTC6373 is a 3-Bit precision instrumentation amplifier with fully differential outputs
https://www.analog.com/media/en/technical-documentation/data-sheets/ltc6373.pdf
properties:
compatible:
@ -28,16 +30,55 @@ properties:
- adi,adrf5740
- adi,hmc425a
- adi,hmc540s
- adi,ltc6373
vcc-supply: true
ctrl-gpios:
description:
Must contain an array of 6 GPIO specifiers, referring to the GPIO pins
connected to the control pins V1-V6.
minItems: 6
Must contain an array of GPIO specifiers, referring to the GPIO pins
connected to the control pins.
ADRF5740 - 4 GPIO connected to D2-D5
HMC540S - 4 GPIO connected to V1-V4
HMC425A - 6 GPIO connected to V1-V6
LTC6373 - 3 GPIO connected to A0-A2
minItems: 1
maxItems: 6
allOf:
- if:
properties:
compatible:
contains:
const: adi,hmc425a
then:
properties:
ctrl-gpios:
minItems: 6
maxItems: 6
- if:
properties:
compatible:
contains:
anyOf:
- const: adi,adrf5740
- const: adi,hmc540s
then:
properties:
ctrl-gpios:
minItems: 4
maxItems: 4
- if:
properties:
compatible:
contains:
const: adi,ltc6373
then:
properties:
ctrl-gpios:
minItems: 3
maxItems: 3
required:
- compatible
- ctrl-gpios

View File

@ -0,0 +1,127 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2024 Analog Devices Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/frequency/adi,admfm2000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADMFM2000 Dual Microwave Down Converter
maintainers:
- Kim Seer Paller <kimseer.paller@analog.com>
description:
Dual microwave down converter module with input RF and LO frequency ranges
from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz.
It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down
conversion path.
properties:
compatible:
enum:
- adi,admfm2000
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^channel@[0-1]$":
type: object
description: Represents a channel of the device.
additionalProperties: false
properties:
reg:
description:
The channel number.
minimum: 0
maximum: 1
adi,mixer-mode:
description:
Enable mixer mode for the channel. It downconverts RF between 5 GHz
and 32 GHz to IF between 0.5 GHz and 8 GHz. If not present, the channel
is in direct IF mode which bypasses the mixer and downconverts RF
between 2 GHz and 8 GHz to IF between 0.5 GHz and 8 GHz.
type: boolean
switch-gpios:
description: |
GPIOs to select the RF path for the channel. The same state of CTRL-A
and CTRL-B GPIOs is not permitted.
CTRL-A CTRL-B CH1 Status CH2 Status
1 0 Direct IF mode Mixer mode
0 1 Mixer mode Direct IF mode
items:
- description: CTRL-A GPIO
- description: CTRL-B GPIO
attenuation-gpios:
description: |
Choice of attenuation:
DSA-V4 DSA-V3 DSA-V2 DSA-V1 DSA-V0
1 1 1 1 1 0 dB
1 1 1 1 0 -1 dB
1 1 1 0 1 -2 dB
1 1 0 1 1 -4 dB
1 0 1 1 1 -8 dB
0 1 1 1 1 -16 dB
0 0 0 0 0 -31 dB
items:
- description: DSA-V0 GPIO
- description: DSA-V1 GPIO
- description: DSA-V2 GPIO
- description: DSA-V3 GPIO
- description: DSA-V4 GPIO
required:
- reg
- switch-gpios
- attenuation-gpios
required:
- compatible
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
converter {
compatible = "adi,admfm2000";
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0>;
switch-gpios = <&gpio 1 GPIO_ACTIVE_LOW>,
<&gpio 2 GPIO_ACTIVE_HIGH>;
attenuation-gpios = <&gpio 17 GPIO_ACTIVE_LOW>,
<&gpio 22 GPIO_ACTIVE_LOW>,
<&gpio 23 GPIO_ACTIVE_LOW>,
<&gpio 24 GPIO_ACTIVE_LOW>,
<&gpio 25 GPIO_ACTIVE_LOW>;
};
channel@1 {
reg = <1>;
adi,mixer-mode;
switch-gpios = <&gpio 3 GPIO_ACTIVE_LOW>,
<&gpio 4 GPIO_ACTIVE_HIGH>;
attenuation-gpios = <&gpio 0 GPIO_ACTIVE_LOW>,
<&gpio 5 GPIO_ACTIVE_LOW>,
<&gpio 6 GPIO_ACTIVE_LOW>,
<&gpio 16 GPIO_ACTIVE_LOW>,
<&gpio 26 GPIO_ACTIVE_LOW>;
};
};
...

View File

@ -22,6 +22,9 @@ properties:
vdd-supply: true
vddio-supply: true
spi-max-frequency:
maximum: 10000000
interrupts:
minItems: 1
maxItems: 2
@ -33,7 +36,10 @@ required:
- compatible
- reg
additionalProperties: false
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
examples:
- |

View File

@ -27,6 +27,9 @@ properties:
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg

View File

@ -43,6 +43,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@ -51,5 +52,7 @@ examples:
compatible = "ti,hdc3021", "ti,hdc3020";
reg = <0x47>;
vdd-supply = <&vcc_3v3>;
interrupt-parent = <&gpio3>;
interrupts = <23 IRQ_TYPE_EDGE_RISING>;
};
};

View File

@ -35,7 +35,9 @@ properties:
- st,lsm6dsv
- st,lsm6dso16is
- items:
- const: st,asm330lhhx
- enum:
- st,asm330lhhx
- st,asm330lhhxg1
- const: st,lsm6dsr
- items:
- const: st,lsm6dstx

View File

@ -4,19 +4,22 @@
$id: http://devicetree.org/schemas/iio/light/ams,as73211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor
title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor and AMS AS7331 UV Sensor
maintainers:
- Christian Eggers <ceggers@arri.de>
description: |
XYZ True Color Sensor with I2C Interface
AMS AS73211 XYZ True Color Sensor with I2C Interface
https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0-b302-c2fd-e30a-c98df87616df
AMS AS7331 UVA, UVB and UVC Sensor with I2C Interface
https://ams.com/documents/20143/9106314/AS7331_DS001047_4-00.pdf
properties:
compatible:
enum:
- ams,as73211
- ams,as7331
reg:
description:

View File

@ -21,6 +21,7 @@ properties:
required:
- compatible
- reg
- vdd-supply
additionalProperties: false

View File

@ -0,0 +1,60 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/magnetometer/voltafield,af8133j.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Voltafield AF8133J magnetometer sensor
maintainers:
- Ondřej Jirman <megi@xff.cz>
properties:
compatible:
const: voltafield,af8133j
reg:
maxItems: 1
reset-gpios:
description:
A signal for active low reset input of the sensor. (optional; if not
used, software reset over I2C will be used instead)
avdd-supply:
description:
A regulator that provides AVDD power (Working power, usually 3.3V) to
the sensor.
dvdd-supply:
description:
A regulator that provides DVDD power (Digital IO power, 1.8V - AVDD)
to the sensor.
mount-matrix:
description: An optional 3x3 mounting rotation matrix.
required:
- compatible
- reg
- avdd-supply
- dvdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
magnetometer@1c {
compatible = "voltafield,af8133j";
reg = <0x1c>;
avdd-supply = <&reg_dldo1>;
dvdd-supply = <&reg_dldo1>;
reset-gpios = <&pio 1 1 GPIO_ACTIVE_LOW>;
};
};

View File

@ -99,6 +99,9 @@ required:
- honeywell,transfer-function
- honeywell,pressure-triplet
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml
additionalProperties: false
dependentSchemas:

View File

@ -8,25 +8,28 @@ title: Honeywell mprls0025pa pressure sensor
maintainers:
- Andreas Klinger <ak@it-klinger.de>
- Petre Rodan <petre.rodan@subdimension.ro>
description: |
Honeywell pressure sensor of model mprls0025pa.
This sensor has an I2C and SPI interface. Only the I2C interface is
implemented.
This sensor has an I2C and SPI interface.
There are many models with different pressure ranges available. The vendor
calls them "mpr series". All of them have the identical programming model and
differ in the pressure range, unit and transfer function.
To support different models one need to specify the pressure range as well as
the transfer function. Pressure range needs to be converted from its unit to
pascal.
To support different models one need to specify its pressure triplet as well
as the transfer function.
For custom silicon chips not covered by the Honeywell MPR series datasheet,
the pressure values can be specified manually via honeywell,pmin-pascal and
honeywell,pmax-pascal.
The minimal range value stands for the minimum pressure and the maximum value
also for the maximum pressure with linear relation inside the range.
The transfer function defines the ranges of numerical values delivered by the
sensor. The minimal range value stands for the minimum pressure and the
maximum value also for the maximum pressure with linear relation inside the
range.
sensor.
Specifications about the devices can be found at:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/
@ -42,6 +45,10 @@ properties:
maxItems: 1
interrupts:
description:
Optional interrupt for indicating End-of-conversion.
If not present, the driver loops for a while until the received status
byte indicates correct measurement.
maxItems: 1
reset-gpios:
@ -50,6 +57,27 @@ properties:
If not present the device is not reset during the probe.
maxItems: 1
honeywell,transfer-function:
description: |
Transfer function which defines the range of valid values delivered by the
sensor.
1 - A, 10% to 90% of 2^24 (1677722 .. 15099494)
2 - B, 2.5% to 22.5% of 2^24 (419430 .. 3774874)
3 - C, 20% to 80% of 2^24 (3355443 .. 13421773)
enum: [1, 2, 3]
$ref: /schemas/types.yaml#/definitions/uint32
honeywell,pressure-triplet:
description: |
Case-sensitive five character string that defines pressure range, unit
and type as part of the device nomenclature. In the unlikely case of a
custom chip, unset and provide pmin-pascal and pmax-pascal instead.
enum: [0001BA, 01.6BA, 02.5BA, 0060MG, 0100MG, 0160MG, 0250MG, 0400MG,
0600MG, 0001BG, 01.6BG, 02.5BG, 0100KA, 0160KA, 0250KA, 0006KG,
0010KG, 0016KG, 0025KG, 0040KG, 0060KG, 0100KG, 0160KG, 0250KG,
0015PA, 0025PA, 0030PA, 0001PG, 0005PG, 0015PG, 0030PG, 0300YG]
$ref: /schemas/types.yaml#/definitions/string
honeywell,pmin-pascal:
description:
Minimum pressure value the sensor can measure in pascal.
@ -58,14 +86,8 @@ properties:
description:
Maximum pressure value the sensor can measure in pascal.
honeywell,transfer-function:
description: |
Transfer function which defines the range of valid values delivered by the
sensor.
1 - A, 10% to 90% of 2^24 (1677722 .. 15099494)
2 - B, 2.5% to 22.5% of 2^24 (419430 .. 3774874)
3 - C, 20% to 80% of 2^24 (3355443 .. 13421773)
$ref: /schemas/types.yaml#/definitions/uint32
spi-max-frequency:
maximum: 800000
vdd-supply:
description: provide VDD power to the sensor.
@ -73,11 +95,26 @@ properties:
required:
- compatible
- reg
- honeywell,pmin-pascal
- honeywell,pmax-pascal
- honeywell,transfer-function
- vdd-supply
oneOf:
- required:
- honeywell,pressure-triplet
- required:
- honeywell,pmin-pascal
- honeywell,pmax-pascal
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml
- if:
required:
- honeywell,pressure-triplet
then:
properties:
honeywell,pmin-pascal: false
honeywell,pmax-pascal: false
additionalProperties: false
examples:
@ -93,10 +130,29 @@ examples:
reg = <0x18>;
reset-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio3>;
interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
honeywell,pmin-pascal = <0>;
honeywell,pmax-pascal = <172369>;
interrupts = <21 IRQ_TYPE_EDGE_RISING>;
honeywell,pressure-triplet = "0025PA";
honeywell,transfer-function = <1>;
vdd-supply = <&vcc_3v3>;
};
};
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
pressure@0 {
compatible = "honeywell,mprls0025pa";
reg = <0>;
spi-max-frequency = <800000>;
reset-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio0>;
interrupts = <30 IRQ_TYPE_EDGE_RISING>;
honeywell,pressure-triplet = "0015PA";
honeywell,transfer-function = <1>;
vdd-supply = <&vcc_3v3>;
};
};
...

View File

@ -24,9 +24,16 @@ properties:
reg:
maxItems: 1
vcc-supply:
description: provide VCC power to the sensor.
label:
description: Unique name to identify which device this is.
required:
- compatible
- reg
- vcc-supply
additionalProperties: false
@ -39,5 +46,6 @@ examples:
tmp117@48 {
compatible = "ti,tmp117";
reg = <0x48>;
vcc-supply = <&pmic_reg_3v3>;
};
};

View File

@ -23,6 +23,9 @@ properties:
compatible:
enum:
- qcom,msm8909-bimc
- qcom,msm8909-pcnoc
- qcom,msm8909-snoc
- qcom,msm8916-bimc
- qcom,msm8916-pcnoc
- qcom,msm8916-snoc

View File

@ -8,7 +8,7 @@ title: Qualcomm RPMh Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
- Odelu Kukatla <okukatla@codeaurora.org>
- Odelu Kukatla <quic_okukatla@quicinc.com>
description: |
RPMh interconnect providers support system bandwidth requirements through

View File

@ -0,0 +1,84 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sm7150-rpmh.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPMh Network-On-Chip Interconnect on SM7150
maintainers:
- Danila Tikhonov <danila@jiaxyga.com>
description: |
RPMh interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM).
See also:: include/dt-bindings/interconnect/qcom,sm7150-rpmh.h
allOf:
- $ref: qcom,rpmh-common.yaml#
properties:
compatible:
enum:
- qcom,sm7150-aggre1-noc
- qcom,sm7150-aggre2-noc
- qcom,sm7150-compute-noc
- qcom,sm7150-config-noc
- qcom,sm7150-dc-noc
- qcom,sm7150-gem-noc
- qcom,sm7150-mc-virt
- qcom,sm7150-mmss-noc
- qcom,sm7150-system-noc
reg:
maxItems: 1
# Child node's properties
patternProperties:
'^interconnect-[0-9]+$':
type: object
description:
The interconnect providers do not have a separate QoS register space,
but share parent's space.
allOf:
- $ref: qcom,rpmh-common.yaml#
properties:
compatible:
enum:
- qcom,sm7150-camnoc-virt
required:
- compatible
unevaluatedProperties: false
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
mc_virt: interconnect@1380000 {
compatible = "qcom,sm7150-mc-virt";
reg = <0x01380000 0x40000>;
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
system_noc: interconnect@1620000 {
compatible = "qcom,sm7150-system-noc";
reg = <0x01620000 0x40000>;
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
camnoc_virt: interconnect-0 {
compatible = "qcom,sm7150-camnoc-virt";
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
};

View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/mtd/partitions/linux,ubi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Unsorted Block Images
description: |
UBI ("Unsorted Block Images") is a volume management system for raw
flash devices which manages multiple logical volumes on a single
physical flash device and spreads the I/O load (i.e wear-leveling)
across the whole flash chip.
maintainers:
- Daniel Golle <daniel@makrotopia.org>
allOf:
- $ref: partition.yaml#
properties:
compatible:
const: linux,ubi
volumes:
type: object
description: UBI Volumes
patternProperties:
"^ubi-volume-.*$":
$ref: /schemas/mtd/partitions/ubi-volume.yaml#
unevaluatedProperties: false
required:
- compatible
unevaluatedProperties: false
examples:
- |
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
reg = <0x0 0x100000>;
label = "bootloader";
read-only;
};
partition@100000 {
reg = <0x100000 0x1ff00000>;
label = "ubi";
compatible = "linux,ubi";
volumes {
ubi-volume-caldata {
volid = <2>;
volname = "rf";
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
eeprom@0 {
reg = <0x0 0x1000>;
};
};
};
};
};
};

View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/mtd/partitions/ubi-volume.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UBI volume
description: |
This binding describes a single UBI volume. Volumes can be matches either
by their ID or their name, or both.
maintainers:
- Daniel Golle <daniel@makrotopia.org>
properties:
volid:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Match UBI volume ID
volname:
$ref: /schemas/types.yaml#/definitions/string
description:
Match UBI volume ID
nvmem-layout:
$ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
description:
This container may reference an NVMEM layout parser.
anyOf:
- required:
- volid
- required:
- volname
# This is a generic file other binding inherit from and extend
additionalProperties: true

View File

@ -94,6 +94,10 @@ properties:
local-bd-address: true
qcom,local-bd-address-broken:
type: boolean
description:
boot firmware is incorrectly passing the address in big-endian order
required:
- compatible

View File

@ -36,20 +36,18 @@ properties:
allOf:
- if:
properties:
compatible:
contains:
const: mac-base
required: [ compatible ]
then:
if:
properties:
compatible:
contains:
const: mac-base
then:
properties:
"#nvmem-cell-cells":
description: The first argument is a MAC address offset.
const: 1
required:
- "#nvmem-cell-cells"
properties:
"#nvmem-cell-cells":
description: The first argument is a MAC address offset.
const: 1
required:
- "#nvmem-cell-cells"
required:
- reg

View File

@ -0,0 +1,18 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/nvmem/nvmem-provider.yaml#
$schema: http://devicetree.org/meta-schemas/base.yaml#
title: NVMEM (Non Volatile Memory) Provider
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
select: true
properties:
'#nvmem-cell-cells':
enum: [0, 1]
additionalProperties: true

View File

@ -1,46 +0,0 @@
--------------------------------------------------------------------------
= Zynq UltraScale+ MPSoC nvmem firmware driver binding =
--------------------------------------------------------------------------
The nvmem_firmware node provides access to the hardware related data
like soc revision, IDCODE... etc, By using the firmware interface.
Required properties:
- compatible: should be "xlnx,zynqmp-nvmem-fw"
= Data cells =
Are child nodes of silicon id, bindings of which as described in
bindings/nvmem/nvmem.txt
-------
Example
-------
firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
nvmem_firmware {
compatible = "xlnx,zynqmp-nvmem-fw";
#address-cells = <1>;
#size-cells = <1>;
/* Data cells */
soc_revision: soc_revision {
reg = <0x0 0x4>;
};
};
};
};
= Data consumers =
Are device nodes which consume nvmem data cells.
For example:
pcap {
...
nvmem-cells = <&soc_revision>;
nvmem-cell-names = "soc_revision";
...
};

View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Zynq UltraScale+ MPSoC Non Volatile Memory interface
description: |
The ZynqMP MPSoC provides access to the hardware related data
like SOC revision, IDCODE and specific purpose efuses.
maintainers:
- Kalyani Akula <kalyani.akula@amd.com>
- Praveen Teja Kundanala <praveen.teja.kundanala@amd.com>
allOf:
- $ref: nvmem.yaml#
properties:
compatible:
const: xlnx,zynqmp-nvmem-fw
required:
- compatible
unevaluatedProperties: false
examples:
- |
nvmem {
compatible = "xlnx,zynqmp-nvmem-fw";
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
soc_revision: soc-revision@0 {
reg = <0x0 0x4>;
};
};
};

View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pwm/opencores,pwm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OpenCores PWM controller
maintainers:
- William Qiu <william.qiu@starfivetech.com>
description:
The OpenCores PTC ip core contains a PWM controller. When operating in PWM
mode, the PTC core generates binary signal with user-programmable low and
high periods. All PTC counters and registers are 32-bit.
allOf:
- $ref: pwm.yaml#
properties:
compatible:
items:
- enum:
- starfive,jh7100-pwm
- starfive,jh7110-pwm
- starfive,jh8100-pwm
- const: opencores,pwm-v1
reg:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
"#pwm-cells":
const: 3
required:
- compatible
- reg
- clocks
additionalProperties: false
examples:
- |
pwm@12490000 {
compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
reg = <0x12490000 0x10000>;
clocks = <&clkgen 181>;
resets = <&rstgen 109>;
#pwm-cells = <3>;
};

View File

@ -26,6 +26,7 @@ properties:
- enum:
- qcom,pm4125-vbus-reg
- qcom,pm6150-vbus-reg
- qcom,pmi632-vbus-reg
- const: qcom,pm8150b-vbus-reg
reg:

View File

@ -47,7 +47,7 @@ properties:
maxItems: 1
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description:
If present, name (or relative path) of the file within the
firmware search path containing the firmware image used when
@ -115,7 +115,7 @@ patternProperties:
maxItems: 1
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description:
If present, name (or relative path) of the file within the
firmware search path containing the firmware image used when

View File

@ -18,7 +18,6 @@ properties:
const: qcom,glink-rpm
label:
$ref: /schemas/types.yaml#/definitions/string
description:
Name of the edge, used for debugging and identification purposes. The
node name will be used if this is not present.

View File

@ -46,7 +46,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -45,7 +45,7 @@ properties:
smd-edge: false
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -80,7 +80,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description:
The name of the firmware which should be loaded for this remote
processor.

View File

@ -42,7 +42,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -47,7 +47,7 @@ properties:
smd-edge: false
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -42,7 +42,7 @@ properties:
smd-edge: false
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -36,7 +36,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
smd-edge: false

View File

@ -46,7 +46,7 @@ properties:
smd-edge: false
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -47,7 +47,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description: Firmware name for the Hexagon core
required:

View File

@ -19,6 +19,11 @@ properties:
- qcom,sm8550-adsp-pas
- qcom,sm8550-cdsp-pas
- qcom,sm8550-mpss-pas
- qcom,sm8650-adsp-pas
- qcom,sm8650-cdsp-pas
- qcom,sm8650-mpss-pas
- qcom,x1e80100-adsp-pas
- qcom,x1e80100-cdsp-pas
reg:
maxItems: 1
@ -49,6 +54,8 @@ properties:
- description: Memory region for main Firmware authentication
- description: Memory region for Devicetree Firmware authentication
- description: DSM Memory region
- description: DSM Memory region 2
- description: Memory region for Qlink Logging
required:
- compatible
@ -63,6 +70,9 @@ allOf:
enum:
- qcom,sm8550-adsp-pas
- qcom,sm8550-cdsp-pas
- qcom,sm8650-adsp-pas
- qcom,x1e80100-adsp-pas
- qcom,x1e80100-cdsp-pas
then:
properties:
interrupts:
@ -71,7 +81,26 @@ allOf:
maxItems: 5
memory-region:
maxItems: 2
else:
- if:
properties:
compatible:
enum:
- qcom,sm8650-cdsp-pas
then:
properties:
interrupts:
maxItems: 5
interrupt-names:
maxItems: 5
memory-region:
minItems: 3
maxItems: 3
- if:
properties:
compatible:
enum:
- qcom,sm8550-mpss-pas
then:
properties:
interrupts:
minItems: 6
@ -79,12 +108,29 @@ allOf:
minItems: 6
memory-region:
minItems: 3
maxItems: 3
- if:
properties:
compatible:
enum:
- qcom,sm8650-mpss-pas
then:
properties:
interrupts:
minItems: 6
interrupt-names:
minItems: 6
memory-region:
minItems: 5
maxItems: 5
- if:
properties:
compatible:
enum:
- qcom,sm8550-adsp-pas
- qcom,sm8650-adsp-pas
- qcom,x1e80100-adsp-pas
then:
properties:
power-domains:
@ -101,6 +147,7 @@ allOf:
compatible:
enum:
- qcom,sm8550-mpss-pas
- qcom,sm8650-mpss-pas
then:
properties:
power-domains:
@ -116,6 +163,8 @@ allOf:
compatible:
enum:
- qcom,sm8550-cdsp-pas
- qcom,sm8650-cdsp-pas
- qcom,x1e80100-cdsp-pas
then:
properties:
power-domains:

View File

@ -51,7 +51,7 @@ properties:
- const: stop-ack
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
maxItems: 1
description:
Relative firmware image path for the WCNSS core. Defaults to
"wcnss.mdt".

View File

@ -1,9 +1,6 @@
TI Davinci DSP devices
=======================
Binding status: Unstable - Subject to changes for DT representation of clocks
and resets
The TI Davinci family of SoCs usually contains a TI DSP Core sub-system that
is used to offload some of the processor-intensive tasks or algorithms, for
achieving various system level goals.

View File

@ -0,0 +1,35 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/reset/sophgo,sg2042-reset.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sophgo SG2042 SoC Reset Controller
maintainers:
- Chen Wang <unicorn_wang@outlook.com>
properties:
compatible:
const: sophgo,sg2042-reset
reg:
maxItems: 1
"#reset-cells":
const: 1
required:
- compatible
- reg
- "#reset-cells"
additionalProperties: false
examples:
- |
rstgen: reset-controller@c00 {
compatible = "sophgo,sg2042-reset";
reg = <0xc00 0xc>;
#reset-cells = <1>;
};

View File

@ -75,6 +75,10 @@ properties:
- riscv,sv57
- riscv,none
reg:
description:
The hart ID of this CPU node.
riscv,cbom-block-size:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@ -106,7 +110,11 @@ properties:
const: 1
compatible:
const: riscv,cpu-intc
oneOf:
- items:
- const: andestech,cpu-intc
- const: riscv,cpu-intc
- const: riscv,cpu-intc
interrupt-controller: true

View File

@ -477,5 +477,12 @@ properties:
latency, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- const: xandespmu
description:
The Andes Technology performance monitor extension for counter overflow
and privilege mode filtering. For more details, see Counter Related
Registers in the AX45MP datasheet.
https://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf
additionalProperties: true
...

View File

@ -1,31 +0,0 @@
Abracon ABX80X I2C ultra low power RTC/Alarm chip
The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, ab1801,
ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the ab1805
is the superset of ab180x.
Required properties:
- "compatible": should one of:
"abracon,abx80x"
"abracon,ab0801"
"abracon,ab0803"
"abracon,ab0804"
"abracon,ab0805"
"abracon,ab1801"
"abracon,ab1803"
"abracon,ab1804"
"abracon,ab1805"
"microcrystal,rv1805"
Using "abracon,abx80x" will enable chip autodetection.
- "reg": I2C bus address of the device
Optional properties:
The abx804 and abx805 have a trickle charger that is able to charge the
connected battery or supercap. Both the following properties have to be defined
and valid to enable charging:
- "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V)
- "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the output
resistor, the other values are in kOhm.

View File

@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
maintainers:
- linux-rtc@vger.kernel.org
properties:
compatible:
description:
The wildcard 'abracon,abx80x' may be used to support a mix
of different abracon rtc`s. In this case the driver
must perform auto-detection from ID register.
enum:
- abracon,abx80x
- abracon,ab0801
- abracon,ab0803
- abracon,ab0804
- abracon,ab0805
- abracon,ab1801
- abracon,ab1803
- abracon,ab1804
- abracon,ab1805
- microcrystal,rv1805
reg:
maxItems: 1
interrupts:
maxItems: 1
abracon,tc-diode:
description:
Trickle-charge diode type.
Required to enable charging backup battery.
Supported are 'standard' diodes with a 0.6V drop
and 'schottky' diodes with a 0.3V drop.
$ref: /schemas/types.yaml#/definitions/string
enum:
- standard
- schottky
abracon,tc-resistor:
description:
Trickle-charge resistor value in kOhm.
Required to enable charging backup battery.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 3, 6, 11]
dependentRequired:
abracon,tc-diode: ["abracon,tc-resistor"]
abracon,tc-resistor: ["abracon,tc-diode"]
required:
- compatible
- reg
allOf:
- $ref: rtc.yaml#
- if:
properties:
compatible:
not:
contains:
enum:
- abracon,abx80x
- abracon,ab0804
- abracon,ab1804
- abracon,ab0805
- abracon,ab1805
then:
properties:
abracon,tc-diode: false
abracon,tc-resistor: false
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
rtc@69 {
compatible = "abracon,abx80x";
reg = <0x69>;
abracon,tc-diode = "schottky";
abracon,tc-resistor = <3>;
interrupts = <44 IRQ_TYPE_EDGE_FALLING>;
};
};

View File

@ -19,7 +19,9 @@ properties:
- items:
- const: atmel,at91sam9260-rtt
- items:
- const: microchip,sam9x60-rtt
- enum:
- microchip,sam9x60-rtt
- microchip,sam9x7-rtt
- const: atmel,at91sam9260-rtt
- items:
- const: microchip,sama7g5-rtt

View File

@ -0,0 +1,39 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/rtc/mediatek,mt2712-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek MT2712 on-SoC RTC
allOf:
- $ref: rtc.yaml#
maintainers:
- Ran Bi <ran.bi@mediatek.com>
properties:
compatible:
const: mediatek,mt2712-rtc
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
rtc@10011000 {
compatible = "mediatek,mt2712-rtc";
reg = <0x10011000 0x1000>;
interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
};

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/rtc/mediatek,mt7622-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek MT7622 on-SoC RTC
allOf:
- $ref: rtc.yaml#
maintainers:
- Sean Wang <sean.wang@mediatek.com>
properties:
compatible:
items:
- const: mediatek,mt7622-rtc
- const: mediatek,soc-rtc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
const: rtc
required:
- reg
- interrupts
- clocks
- clock-names
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/mt7622-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
rtc@10212800 {
compatible = "mediatek,mt7622-rtc", "mediatek,soc-rtc";
reg = <0x10212800 0x200>;
interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_LOW>;
clocks = <&topckgen CLK_TOP_RTC>;
clock-names = "rtc";
};

View File

@ -1,14 +0,0 @@
Device-Tree bindings for MediaTek SoC based RTC
Required properties:
- compatible : Should be "mediatek,mt2712-rtc" : for MT2712 SoC
- reg : Specifies base physical address and size of the registers;
- interrupts : Should contain the interrupt for RTC alarm;
Example:
rtc: rtc@10011000 {
compatible = "mediatek,mt2712-rtc";
reg = <0 0x10011000 0 0x1000>;
interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
};

View File

@ -1,21 +0,0 @@
Device-Tree bindings for MediaTek SoC based RTC
Required properties:
- compatible : Should be
"mediatek,mt7622-rtc", "mediatek,soc-rtc" : for MT7622 SoC
- reg : Specifies base physical address and size of the registers;
- interrupts : Should contain the interrupt for RTC alarm;
- clocks : Specifies list of clock specifiers, corresponding to
entries in clock-names property;
- clock-names : Should contain "rtc" entries
Example:
rtc: rtc@10212800 {
compatible = "mediatek,mt7622-rtc",
"mediatek,soc-rtc";
reg = <0 0x10212800 0 0x200>;
interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_LOW>;
clocks = <&topckgen CLK_TOP_RTC>;
clock-names = "rtc";
};

View File

@ -18,7 +18,13 @@ allOf:
properties:
compatible:
const: xlnx,zynqmp-rtc
oneOf:
- const: xlnx,zynqmp-rtc
- items:
- enum:
- xlnx,versal-rtc
- xlnx,versal-net-rtc
- const: xlnx,zynqmp-rtc
reg:
maxItems: 1
@ -48,6 +54,9 @@ properties:
default: 0x198233
deprecated: true
power-domains:
maxItems: 1
required:
- compatible
- reg

View File

@ -55,6 +55,7 @@ required:
allOf:
- $ref: serial.yaml#
- $ref: rs485.yaml#
- if:
properties:
compatible:

View File

@ -30,6 +30,7 @@ properties:
- items:
- enum:
- fsl,imx93-lpuart
- fsl,imx95-lpuart
- const: fsl,imx8ulp-lpuart
- const: fsl,imx7ulp-lpuart
- items:

View File

@ -59,6 +59,7 @@ properties:
- renesas,hscif-r8a779a0 # R-Car V3U
- renesas,hscif-r8a779f0 # R-Car S4-8
- renesas,hscif-r8a779g0 # R-Car V4H
- renesas,hscif-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-hscif # R-Car Gen4
- const: renesas,hscif # generic HSCIF compatible UART

View File

@ -143,6 +143,8 @@ allOf:
then:
required:
- samsung,uart-fifosize
properties:
reg-io-width: false
unevaluatedProperties: false

View File

@ -88,7 +88,7 @@ properties:
TX FIFO threshold configuration (in bytes).
patternProperties:
"^(bluetooth|bluetooth-gnss|gnss|gps|mcu)$":
"^(bluetooth|bluetooth-gnss|gnss|gps|mcu|onewire)$":
if:
type: object
then:

View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/serial/st,asc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STi SoCs Serial Port
maintainers:
- Patrice Chotard <patrice.chotard@foss.st.com>
allOf:
- $ref: serial.yaml#
properties:
compatible:
const: st,asc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
st,hw-flow-ctrl:
description: When set, enable hardware flow control.
type: boolean
st,force-m1:
description: When set, force asc to be in Mode-1. This is recommended for
high bit rates above 19.2K.
type: boolean
required:
- compatible
- reg
- interrupts
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/stih407-clks.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
serial@9830000 {
compatible = "st,asc";
reg = <0x9830000 0x2c>;
interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
};
...

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